A new project by Apple aims to improve Ruby on MacOS X. The MacRuby project is a port of Ruby 1.9 to the Objective-C runtime.

We talked to Laurent Sansonetti of the MacRuby project to find out what the project is about and how it works.

InfoQ: Is MacRuby an Apple-sponsored project?

Laurent Sansonetti: MacRuby is a free software project created by Apple. Currently the people around the project are Apple employees, though we definitely want to accept outside contributions, which is why we decided to open the project development on MacOSForge, and work on it in a public way.

InfoQ: You based MacRuby on Ruby 1.9/YARV. How much work was it to go from vanilla Ruby 1.9 to MacRuby? Was it mostly about changing object creation? (from Ruby's way to using Objective-C objects). What else had to be changed?

Laurent Sansonetti: The Ruby object data structure had to be modified to conform to the Objective-C object data structure, so that a Ruby object can be casted at the C level as an Objective-C object.

Then, the object allocator was modified to use the Objective-C one instead, which means that all objects (Ruby and Objective-C) are allocated from the same memory pool.

Finally, the traditional Ruby garbage collector was removed and instead we use the Objective-C garbage collector. This change wasn't very easy because the collector runs by default in generational mode, and expects you to appropriately set "write-barriers" every time you register an object in the object store, because it collects young generation of objects based on this information.

InfoQ: How does the creation of the Objective-C classes, that represent Ruby classes, happen? Are they all created at runtime dynamically?

Laurent Sansonetti: The Objective-C classes are created at the same time you define the Ruby classes. Reciprocally, when you access an Objective-C class from MacRuby, it will lazily import it in YARV.

InfoQ: On the Ruby objects, are the Objective-C methods visible?

Laurent Sansonetti: Yes, and vice-versa, Ruby methods are also exposed in the Objective-C world.

InfoQ: A topic of debate in the Ruby space is ObjectSpace. JRuby 1.1 has deactivated it by default. Do you know how Objective-C can do ObjectSpace functionality without a performance hit?

Laurent Sansonetti: All MacRuby objects are allocated from the same memory pool, more precisely a malloc zone (the /usr/include/malloc/malloc.h header file has more details). It is therefore very easy to walk through the zone and yield all objects in it. This functionality comes for free. However, please note that calling ObjectSpace#each_object is significantly slower in MacRuby than vanilla Ruby, because it will return *all* objects, including pure Objective-C objects that are created by frameworks you require!

InfoQ: What's the compatibility situation? I saw that Strings are based on NSStrings - are there any compatibility problems with that? Are native extensions compatible yet?

Laurent Sansonetti: Currently the Ruby String class just inherits from NSString, to perform fast String to NSString conversion. So there is no compatibility problem at the moment.

However, in the very near future, we plan to re-implement the Ruby primitive classes (String, Array and Hash) using their CoreFoundation equivalent (CFString, CFArray and CFDictionary), to unify functionality but also to be able to perform costless conversion between both runtimes. Because we internally noticed that in a typical application, most of the objects that cross the runtime are primitive types.

This change might introduce some compatibility problems, however we will do our best to keep everything compatible with 1.9, and also C extensions.

InfoQ: What are the plans for MacRuby's future?

Laurent Sansonetti: The primary goal of MacRuby is to allow developers to write Cocoa applications that perform extremely well in Ruby, which is not possible with RubyCocoa, the technology we introduced on Mac OS X Leopard (and that we will still continue to support). In order to perform that goal, we still have some work to do. We also want MacRuby to perform well on other use cases too. The current changes, but also the changes we plan to introduce soon, will definitely impact them. We will release a milestone plan soon, as well as a first release! Stay tuned.

InfoQ Weekly Newsletter

Join a community of over 250 K senior developers by signing up for our newsletter. If you are based in the EEA, please contact us so we can provide you with the protections afforded to you under EEA protection laws.

Is your profile up-to-date? Please take a moment to review and update.

Email Address

Note: If updating/changing your email, a validation request will be sent

Company name:

Keep current company name

Update Company name to:

Company role:

Keep current company role

Update company role to:

Company size:

Keep current company Size

Update company size to:

Country/Zone:

Keep current country/zone

Update country/zone to:

State/Province/Region:

Keep current state/province/region

Update state/province/region to:

Subscribe to our newsletter?

Subscribe to our architect newsletter?

Subscribe to our industry email notices?

You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.

We notice you're using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.