Dude, Laconian - iOS 5 already enables GC (a generational one at that), which already came out for regular Cocoa in in obj-c 2.0
You can bet your socks a lot of devs for typical iOS apps will be using GC.
I dunno what GC algorithm is used for MacRuby, I don't see how the upper limit of performance will be much different since obj-c uses dynamic dispatch the same, and Google/Mozilla is making strides in type inference.
Dyanamically typed languages might be pretty close to static language performance (with properly written code since the JIT is still dumb compared to a human) pretty soon.
What are you talking about? There is no GC in iOS 5. The only GC in the Objective-C world is the one on the Mac and it's pretty much the off the shelf Boehm one.
The only thing iOS has is ARC. This is a compile time reference counting solution. This doesn't work with ruby in it's current form in any way.
| iOS 5 already enables GC (a generational one at that), which already came out for regular Cocoa in in obj-c 2.0
Any links?
Otherwise, I assume you're referring to ARC (Automatic Reference Counting) which is not the same as a Garbage Collector.
In summary, based on code analysis the compiler(I think this works only with the LLVM compiler) inserts code for sending [ release] messages for you.
MacRuby uses the same garbage collector as Objective-C, libauto. Which, incidentally, is not what iOS 5 includes. The "garbage collection" in iOS 5 is Automatic Retain Counting, a compiler feature based on static analysis rather than runtime scanning (it's certainly not generational).
You can bet your socks a lot of devs for typical iOS apps will be using GC.
I dunno what GC algorithm is used for MacRuby, I don't see how the upper limit of performance will be much different since obj-c uses dynamic dispatch the same, and Google/Mozilla is making strides in type inference.
Dyanamically typed languages might be pretty close to static language performance (with properly written code since the JIT is still dumb compared to a human) pretty soon.