Hacker News Reader

Comment by zefhous | Hacker News Reader

The solution? MacRuby!

Take the surplus of enthusiasm for Ruby, combine it with the high demand for iOS developers, and there you have it!

Now if only Apple would make MacRuby a first-class language for developing iOS apps...

It'd be second class in terms of performance. Native code execution speed is one of iOS device's strongest selling points vs. Android, which has a few GC hiccups here and there. Apple is probably more inclined to push the tool that yields the best performance for its users, perhaps even at the expense of developers' productivity.

I think you should look into what MacRuby is. It includes an AOT native code compiler. It's still slower than Objective-C for various reasons — for example, it can't use unboxed primitives and it often needs to do extra work to bridge the gap between Ruby's dynamically typed world and the static C types of framework functions — but it is native code produced by LLVM just like a normal application.

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.

| 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.

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.

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).

Is MacRuby even a second-class language for developing iOS apps yet? Last I checked they hadn't got anything more than a proof-of-concept going. I thought it was mainly a Mac-focused technology.

No. You can't build iOS apps with it, but you can build OS X apps — even for the App Store.

The main problem in my understanding is the lack of garbage collection on iOS. Someone mentioned that iOS 5 enabled GC, but I think maybe they are referring to ARC (Automatic Reference Counting), which isn't GC even though it solves the same problem.

Yeah, I remember way back when, lrz proposed implementing something very similar to ARC for MacRuby to make it work on the iPhone, and I'm pretty sure somebody actually implemented a proof-of-concept, but I didn't think it went anywhere. I would have been pleased to find out I'd just missed it, though.

I like Ruby. I spend most of my professional day writing Ruby code. I'm definitely not against the idea of adding Ruby as a first class language.

However, Objective-C is similar enough to Ruby that people already well versed in Ruby should have no trouble just using Objective-C. At least for me, when I realized Objective-C was essentially Ruby with C-style syntax, it immediately made sense. I guess YMMV.

The real hard part is learning the beast that is Cocoa/Cocoa Touch. I was able to learn Objective-C in minutes, but learning the frameworks took much longer. You are going to have to do that no matter what language you choose, unfortunately. The APIs have been reasonably consistent across all of the languages they have been implemented on, so I don't think choosing Ruby for your project is really going to speed up the process all that much, if at all.

Reply on news.ycombinator.com