MacRuby, changing the Ruby ecosystem

What’s MacRuby?

MacRuby is an Apple-sponsored, open source, full Ruby implementation on top of Objective-C runtime. In other words, whatever code runs on Ruby 1.9, should/will run on MacRuby. Yes, you read correctly, MacRuby can/will be able to run all your Ruby code. That means that eventually you will even be able to run your Rails/Sinatra/new-sexy-ruby-framework app on MacRuby.

Unlike RubyCocoa, MacRuby is not a bridge, it is a full implementation of the Ruby language on top of Apple’s Objective-C runtime. Taking a huge shortcut, MacRuby implements the Ruby syntax by aliasing it to the Obj-C language counterpart. A Ruby string instance is really in fact, an instance of NSMutableString. This is obviously transparent for you as a developer since you have the same Ruby API, but it also means that MacRuby can make use of the various Objective-C’s goodies such as native threads,  garbage collector in the background as well as the runtime performance.

On top of that, you have full access to the Obj-C API from your Ruby code. (tip: in macirb, try “my string”.methods(true, true).sort to see the available Ruby + Objective-C methods on your String instance)  The reason why having access to Objective-C is important is because it gives you the possibility to write native Cocoaapps using Ruby. For those who don’t know Cocoa, is a set of APIs for MacOSX development.

However, note that even though, the Cocoa support is almost complete and stable, MacRuby is still in development, especially on the Ruby side of things.

What is it not?

  • MacRuby is not a fork of Ruby. Full rubyspec compliance is expected! It’s true that MacRuby supports smalltalk/Obj-C method selectors so it might be considered a language superset.
  • MacRuby is not limited to the OSX platform. All its dependencies are open source and could possibly be compiled for other POSIX-based systems such as Linux.. (not done yet)
  • Even if MacRuby’s primary goal is to allow you to write efficient Cocoa apps, it does not mean that MacRuby is limited to that.
  • MacRuby doesn’t require you to learn Objective-C in order to develop Cocoa apps. (you just need to understand Obj-C selectors)

What’s coming up?

The current version of MacRuby (today being the 27th of May 2009) is version 0.4. You might have heard of things about MacRuby crazy performance, LLVMAOT compilationAOT compilation etc… This is all happening in the ‘experimental’ branch.

What’s going on is that up to MacRuby 0.5, MR was  using YARV (Ruby 1.9 interpreter) on top of Obj-C and which obviously limited MacRuby’s  to YARV’s performance. After RubyConf 2008, Laurent Sansonetti, MacRuby’s lead developer, decided to try removing YARV to only keep its AST and experiment with using LLVM instead of the 1.9 interpreter.

This switch turned out to be very promising and was noticed right away by influential people such as IBM’s Antonio Cangiano. Since then, performance and compatibility have increased. Laurent even started working on an Ahead Of Time (AOT) compiler: What’s really impressive is that in this specific example (Fibonacci sequence), MacRuby’s compiled code is faster than Objective-C! But let’s not jump the gun. First this is a very very early prototype and most of your apps won’t be using Fib. sequences ;) In this case, MacRuby’s recursive method dispatch is faster but again, this is just a proof of concept and even though MacRuby is getting close to Obj-C speed, it’s still far from matching Obj-C’s impressive performance.

What this basically means is that you will be able to compile your Ruby code down to binary code. Imagine, taking your Rails app and compiling it down to a binary file that you can just push to your server :) But really, what’s almost more important is that Ruby will get closer to Objective-C’s speed.

Why will MacRuby change the Ruby ecosystem?

As a web developer, getting better performance is great. But Ruby is already fast enough. Rails is faster than any PHP framework out there and when doing Merb’s benchmarks we proved that Ruby for the web can definitely be fast.

Now if MacRuby ends up running 3-7X faster than Ruby 1.9 (no one can tell for sure), existing Ruby developers will certainly be really pleased but it will probably affect more people outside of our community than within. Let’s face it, our community isn’t that big but it’s growing fast and people are mainly coming to Ruby for its web frameworks. But Ruby has much more than that to offer. Desktop applications, video games, scientific computation and even embedded apps. Apple is betting on Ruby probably because of the fact that they see the potential in the language itself.

Would people still use Java if Ruby is as fast/faster than Java? Probably! Would they think about using Ruby for their next project? I would certainly hope so!

Ruby is viral, it’s such a great language, people who have started using it are having a hard time going back to what they used before. But to spread the ‘love’, we need to give people the opportunity to discover why Ruby is so great and to do that, we need to make sure Ruby is relevant to them. By making Ruby a realistic option to write desktop/mobile applications, we are targeting a new audience. An experienced audience which will be able to bring a new perspective to our ecosystem and help it grow.

Of course, MacRuby isn’t the only implementation out there trying to do that. JRuby and IronRuby are also very interesting projects. My take on it, is that MacRuby will be able to change things because of its new approach and potential community. It will more than likely be the first Ruby implementation compiling down to binary code, it will more than likely be the fastest implementation and it will more than likely draw a different type of developer.

Does it mean that JRubyIronRubyBlueRuby will be useless? Absolutely not! Matz is the first one to encourage diversity and I agree that this is a great way to move forward. These projects solve different problems and all have pros and cons, but they also all share a similar goal: making Ruby a better and more popular language outside of its original community. JRuby, IronRuby and MacRuby bring Ruby to the respective Java, .net and Cocoa communities, and indirectly bring fresh developers to Ruby. These implementations are critical in the way they actually bridge existing communities and in the end, all Rubyists will benefit from it. Also, even though MacRuby and IronRuby are in active development, JRuby is the only mature alternative to MRI/YARV at this point and it proved that Ruby can coexist in a different community as well as contribute a lot of interesting things back to the Ruby community.

To summarize, I see tremendous potential in MacRuby. There is the obvious technical aspect of the implementation, but also the indirect affect MacRuby could have on our community. I believe that MacRuby is an agent of change and will help bringing more diversity to our community. It will change mentalities and push Ruby to places where it’s being struggling to make a mark. I can see the so-called “Enterprise” people looking at Ruby differently. I also think that MacRuby has the potential to be at the origin of a new type of hybrid application, mixing desktop/mobile/distributed applications with centralized web applications. Why not dream of p2p applications/games using a subset of Rails to communicate between each other and with a central server?


If you are interested in learning more about MacRuby, check the list of resources available on the MacRuby site.

Rich Kilmer and I are also working on a documentation application for Cocoa and HotCocoa as well as a MVC framework for writing Cocoa apps using HotCocoa (HotCocoa is a thin, idiomatic Ruby layer that sits above Cocoa and other frameworks).

Make sure to keep an eye on @macruby and the MacRuby website if you want to keep track of the latest news.

Similar Posts

, , , , , , ,

  1. #1 by Sean McCleary - May 27th, 2009 at 14:03

    Question: Can or will MacRuby run outside of OSX? I was just reading a little on Objective-C on wikipedia and I read:

    “Generic Objective-C programs which do not make use of these libraries can also be compiled for any system supported by gcc, which includes an Objective-C compiler.”

    If MacRuby does not depend on any Coca specific libraries, does that mean that MacRuby can be compiled and used on non-OSX operating systems?

  2. #2 by Matt Aimonetti - May 27th, 2009 at 14:07

    @sean as mentioned in the blog post: “MacRuby is not limited to the OSX platform. All its dependencies are open source and could possibly be compiled for other POSIX-based systems such as Linux.. (not done yet)”
    A group of people already started looking into porting MacRuby to Linux. Technically, there isn’t any reasons for it not to work.

    • #3 by Sean McCleary - May 27th, 2009 at 14:11

      @Matt Thank you. I need to read closer.

  3. #4 by Matt Aimonetti - May 27th, 2009 at 14:13

    By the way, I did not mention Rubinius, DiamondBack, CrossTwine and other implementations on purpose. Not because they are inferior, but because they don’t bridge communities. However, they also have a very important mission, which is to make our ecosystem better, by provided us with better tools and performance.

  4. #5 by Mani - May 27th, 2009 at 14:19

    When can we expect to use MacRuby to build iPhone apps? That would be killer!

  5. #6 by Matt Aimonetti - May 27th, 2009 at 14:22

    @mani technically, now that MacRuby compiles down to binary, it’s “doable”. I would say it might happen pretty soon after 0.5 gets released.

    • #7 by Nate - June 3rd, 2009 at 09:46

      Wow, +1 for macruby on iPhone. That would be a total game-changer! Is there any clue of when 0.5 is going to be cooked?

  6. #8 by rd - May 27th, 2009 at 14:28

    No Objc programmer would write fib the way Laurent has written.
    It would be written like a C function call and just called from ObjC method. So the performance would be close to the C version something like .6XX sec

    MacRuby is not coming to iPhone anytime soon. No GC. NO LLVM. etc. all the VM stuff would eat the battery for lunch.
    ruby people really need to learn the basic before they start spewing nonsense. There is better chance that WebObjects would be rewritten with MacRuby instead of Java than it is coming to iPhone.

    • #9 by Laurent Sansonetti - May 27th, 2009 at 16:27

      This objc version of fib that I wrote in that pastie was just a test to compare method dispatch, it is obviously not representative of the way you should write fib in a real ObjC app. This was a simple micro benchmark, nothing more.

      Regarding your thought about MacRuby not coming to the iPhone soon: we don’t need to generate code dynamically anymore if we can compile it ahead-of-time and the GC could be potentially emulated using NSAutoreleasePools at crucial places. And at the very end, the runtime overhead would be pretty much the same as a typical Objective-C program.

      • #10 by rd - May 27th, 2009 at 19:51

        I understand that very well. but your fans who keep
        saying that ruby is now beating objc is what I am objecting.
        The fact that they cannot seem to remember that
        whole thing is built on top of objc runtime seems even more troubling.

        As far as iphone is concerned. so the whole thing
        is just program with objc runtime having ruby syntax code.
        so every app will link to standard ruby libraries statically.
        so no sharing and no official support from Apple.

        • #11 by Matt Aimonetti - May 27th, 2009 at 22:05

          @rd nobody said that Ruby was faster than obj-c.
          Read again: “MacRuby’s recursive method dispatch is faster but again, this is just a proof of concept and even though MacRuby is getting close to Obj-C speed, it’s still far from matching Obj-C’s impressive performance”

          Regarding the iPhone platform, let’s wait and see.

  7. #12 by Matt Aimonetti - May 27th, 2009 at 14:35

    @rd MacRuby 0.5 uses LLVM, and the GC problem has been addressed by other implementation like nu. (I believe nu deals with that at compilation time).

  8. #13 by Godfrey Chan - May 27th, 2009 at 15:15

    Great article! Don’t think I am going to write a native app with Ruby/Cocoa stuff mixed anytime soon, but I am totally excited about the performance/LLVM/compilation stuff!

  9. #14 by Tom Mancino - May 27th, 2009 at 18:53


    Very cool article. I really think that MacRuby will take off when it is available to write Iphone apps. I hope the issues addressed in the comments can be easily overcome.

  10. #15 by Paul Crawford - May 27th, 2009 at 21:26

    Great article Matt, I am really excited by MacRuby, I’ve been developing mainly in ruby and objective-c for the last couple of years and this is like the perfect combination from my point of view. I think you are dead on with your observations regarding MacRuby’s potential.

  11. #16 by Luigi Montanez - May 28th, 2009 at 05:04

    From my viewpoint, iPhone support is really what will make MacRuby something I would try. The iPhone market is just so much more appealing than the Mac OS X market. If I did develop a Mac app, I’d probably want it to be a companion to an iPhone app anyway…

  12. #17 by chad - May 28th, 2009 at 07:32

    Two additional fib implementations in pure Ruby here:

    Fibonacci numbers in Ruby

    (just in case someone is interested in different fib implementations)

  13. #18 by rd - May 28th, 2009 at 13:04

    Matt Aimonetti :
    @rd nobody said that Ruby was faster than obj-c.
    Read again: “MacRuby’s recursive method dispatch is faster but again, this is just a proof of concept and even though MacRuby is getting close to Obj-C speed, it’s still far from matching Obj-C’s impressive performance”
    Regarding the iPhone platform, let’s wait and see.

    Well all those twitter post I saw saying macruby is faster than objc where just hyperbole right.
    Why would the author bold the statement.
    Why not campare to JRuby or ruby19.

    you see objc people have already gone thru this
    kind of bs when cocoa was suppose to rewritten using Java.
    How the carbon people wouldn’t touch cocoa with ten foot pole.

    As far as touting cross platform. gnustep has been trying get
    to 1.0 since 1995. their runtime is different. objc 2.0 is not there. gc is different. theoretically everything is possible it is another thing for companies to hire you to code in macruby for
    their enterprise like they do for server side ruby.

  14. #19 by George Bray - May 28th, 2009 at 14:49

    Great post, thanks. Ruby is beautiful and easy, objC is ugly and hard. It will be a great day when MacRuby can make iPhone apps. Excellent you’re thinking about automatically handling GC. Having to deal with memory management is so 80′s.

  15. #20 by Alex Vollmer - May 28th, 2009 at 20:32

    One of the thing I’d like to see (and work on) is bringing a lot of the Ruby testing tools to Cocoa development. Having something like Cucumber for integration testing Cocoa apps would be total god-send. MacRuby has a huge potential to significantly improve the level of automated-testing technology in Cocoa-land.

  16. #24 by MySchizoBuddy - May 30th, 2009 at 11:17

    I don’t get RD’s argument of why Macruby won’t work under iphone and why is he soo betting against it and hating on it?

    if macruby code is just objective-c underneath and hotcocoa is just cocoa underneath. Why won’t it run on the iphone.

  17. #25 by Chuck - May 30th, 2009 at 12:02

    If MacRuby doesn’t have any Mac-specific dependencies, why doesn’t it even run on 10.4? It seems like it’s dependent on AutoZone and the 10.5 version of Cocoa at the very least. Is this not the case?

    • #26 by MySchizoBuddy - May 30th, 2009 at 12:53

      macruby doesn’t depend on cocoa, hotcocoa does.

    • #27 by MySchizoBuddy - May 30th, 2009 at 12:56

      macruby depends on Obj-2.0, i think Tiger has v1.0

  18. #28 by Jocelyn - June 1st, 2009 at 05:38

    I hope objective-C 2.0 will be sometimes available on linux, then …

Comments are closed.