MacRuby Marches Onwards

It was just several months ago that we first began to mention MacRuby on Ruby Inside, but it's been coming on by leaps and bounds since then. MacRuby is a Mac OS X-based Ruby implementation that works on the Objective C runtime. It's based on Ruby 1.9 and uses the YARV VM (as Ruby 1.9 does) but will be switching to LLVM at the next major release. MacRuby is attempting to make Ruby a first class OS X development language.

The developments so far have been very promising and a lot of MacRuby news has come out in the past few weeks, which I'll try to summarize:

MacRuby 0.4 Released

MacRuby 0.4 was released a few weeks ago. Lots of new goodies too: a threaded garbage collector, full 64 bit support, DTrace probes (DTrace being a rather cool tracing feature in Solaris, FreeBSD and OS X), an Objective C API (so that MacRuby can be controlled from other Cocoa apps), and new Xcode templates.

MacRuby's samples are now particularly compelling. You can put together a fully(ish) featured OS X application in Ruby (using MacRuby), use Cocoa, and look fully native, but without the downsides of RubyCocoa (horrendous method names, for one). It's also possible to package up MacRuby based apps into regular OS X applications without too much difficulty, since MacRuby's runtime can be bundled as a framework. You should also check out HotCocoa::Graphics - an easy-to-use graphics library that comes along with MacRuby.

New site

MacRuby has signalled its transition into implementation adolescence by getting a snazzy new official Web site at http://www.macruby.org/

It's not just a snazzy design though. This is probably my favorite Ruby implementation site already (although ruby-lang.org is pretty good) in terms of actually being useful. Relevant events, install instructions, blog posts, and download links are right there on the front page, along with the obligatory code example.

Experimental 0.5 announced and.. the controversial benchmarks

MacRuby 0.5 has yet to arrive but it's already causing a stir..

The biggest change is that MacRuby will be switching to an LLVM-based JIT compiler (layman's translation: it should be super fast) and a new IO subsystem. The early performance benchmarks in the alpha of all alphas of 0.5 were so exciting that Antonio Cangiano wrote a blog post with lots of benchmark results and cool graphs and (with some disclaimers) stated "that at this stage of the game, MacRuby 0.5 is the fastest Ruby implementation around." This caused, as most benchmarking tends to, a little bit of controversy to say the least.

I can't blame Antonio's enthusiasm, however. The early benchmarks show a generally positive picture of MacRuby's potential performance with just a few benchmarks working out slow than Ruby 1.9.1 and the majority coming in at between 1.1 to 8 times faster than Ruby 1.9.1 (though with a very high standard deviation). Charles Nutter rightly pointed out that it's wrong to call MacRuby the fastest anything just yet, since it still crashes for a lot of scripts and it's a long way from being mature. He cites MagLev as an example of why premature performance parading can backfire.

The MacRuby team might have a different answer, but I'd say.. there's no point in using MacRuby in the near future /unless/ you want to use the Mac-specific features. Of course, from 0.5 and beyond MacRuby might be a lot faster and totally compatible with MRI, meaning, yes, you should use it, but it seems to be far from that point so far.

For the current moment, however, MacRuby is mostly useful if you want to use the Cocoa APIs in a nice way from Ruby.

Daniel Berger says:April 1, 2009 at 7:32 pm

@Brian - HEATHEN! How dare you question the cult of Mac! Nobody deploys on OS X, but nevermind that! We must continue to develop a version of Ruby that only works on a Mac so we make cool Cocoa apps! Cocoa apps that could be built with standard Ruby and a C extension library, but nevermind that!

George McGrumble says:April 1, 2009 at 8:16 pm

@Daniel - MacRuby makes it much more pleasant to develop Cocoa apps. If you don't see an advantage in that, well then perhaps Ruby is not really right for you in the first place.

If you don't see an advantage in that, well then perhaps Ruby is not really right for you in the first place.

I myself don't see an advantage to having something that makes it more pleasant to develop Cocoa apps - I don't develop Cocoa apps in the first place.

But then I've always seen my Mac as more a 'nix box with a fancy windows manager than 'a mac'. Perhaps I'm odd.

pjm says:April 1, 2009 at 9:54 pm

Nobody deploys on Macs? Wow, thanks for telling me: I almost thought that I deployed on Macs for a moment...

Perhaps it's worth pointing out that not every Rails application (for example) has a constant stream of hundreds or thousands of users per minute, so deploying to desktop machines is perfectly feasible in many situations. For example, I have a number of Rails applications that have a grand total of about 50 users each (by design, not by unpopularity!), and those users might spend 15 minutes each per week interacting with them. All apps sit perfectly happily, and respond quite quickly, on a desktop iMac, but if there's a significantly faster ruby available (and it runs Rails down the track) it'd be great to swap out MRI for MacRuby. Heck, even for developing applications for deployment elsewhere, or day to day scripts with or without a GUI, it'd be great to have a faster ruby in OS X.

Is the ruby standard library able to be used from MacRuby? Can I require, for example, 'net/http'?

George McGrumble says:April 2, 2009 at 4:16 am

I myself don't see an advantage to having something that makes it more pleasant to develop Cocoa apps - I don't develop Cocoa apps in the first place.

So you're saying that you're unable to perceive the advantage of something unless you personally have a need for it? Besides, you have a Mac. Perhaps someone else will now develop an app that you find useful.

Yes, net/http works just fine. It's really gems that have problems running in MR right now. You can vendor some and include them in your project, but some just won't install in macgems (here's looking at you hpricot...).

thanks. I had got the impression it was just a ruby interpreter - the stdlib + cocoa. I am pleased to see I can still get the productivity gains of the ruby stdlib. I am defiantly going to download it now.

Ade says:April 3, 2009 at 2:14 am

"So many grouches..."

So true. Like my mom likes to say, if you don't have something nice to say, why say anything at all? It's not like you're funding this project with your tax dollars.

ab5tract says:April 6, 2009 at 5:36 pm

Well, Cocoa is all well and good but are they aiming at cross platform support by trying to be compatible with GNUStep as well?

I don't think so, there's a reason it is called MacRuby! And imo it's not worth to get to the lowest common denominator to make it work on both platforms. Although I don't have any experience (yet) with Cocoa, it looks like a really nice framework - feature-wise, not syntax :)