The ObjC object model is very similar to Ruby's object model.
ObjC's way of handling mundane data structures (strings, arrays, hashes) is (once you learn to stop worrying and love long sequences of calls to very long method names) very similar to how Ruby addresses the same problems.
ObjC lets you drop into vanilla C code when you want to.
ObjC doesn't impose GC.
ObjC implements a form of duck typing.
You might be surprised at how good a fit ObjC is for a game engine you prototyped in Ruby, as opposed to C++.
I always got a "stay on the golden path and away from ObjC++" vibe from ObjC++, kind of like trying to ask Rails to do database stuff without using ActiveRecord in 2008.
You can easily write C++ code without having to bridge ObjC's object system to C++'s object-and-generics system: provide a simple C API to your C++ libraries.
But the other thing is, one reason to do ObjC at all is to avoid all the heartache that comes bundled with C++.
Obj-C++ is working well for me so far and the STL is much better than Obj-C's awkward and slow collection classes for anything that needs to run fast or that requires significant algorithmic complexity.
One of the nice things about going back from Ruby to a C language is, it's hard to think of anything you could do in the C language that would be as non-performant as Ruby. As slow as ObjC's collections are, they're faster than Ruby's.
Yeah, and they're fast enough for a lot of things, but I'm doing DSP at 44.1k/sec and even C++ virtual functions are too slow for that. But I can use an STL vector at no penalty over a native array.
It is just a shame that in some areas Objective-C is still lacking compared with more modern languages:
- a proper module system;
- reliance on the primitive #import/#include which slows down compilation
- no namespacing, relying instead on conventions to avoid clashes
