So, What About Rubinius

Rubinius is important. A whole lot of folks agree. Ola Bini wrote up a whole post about how important he thinks it is. In it, he writes:

In fact, I’m getting more and more convinced that for the people that don’t need the things Java infrastructure can give you, Rubinius is the most important project around, in Ruby-land. More than that, Rubinius is MRI done right. If nothing substantial changes in the current timeline and plans for Ruby 1.9.1, I predict that Rubinius will be the CRuby implementation of choice within 6 months. Rubinius is an implementation done the way MRI should have been.

He also lays out a number of reasons that he feels this way:

• It is byte code based. This means it’s easier to handle performance.
• It has a pluggable, very clean architecture, meaning that for example garbage collection/object memory can be switched out to use another algorithm.
• It is designed to be thread safe (though this is not really true yet), and Multi-VM capable.
• It works with existing MRI extensions.
• Most of the code is written in Ruby.
• It gives you access to all the innards, directly from your Ruby code (stuff like MethodContexts/BlockContexts, etc).
• The project uses Valgrind to ensure that the C code written is bullet proof.

The meme that rubinius matters has also spread to Sun, who sponsored the recent Rubinius Sprint in Denver. Tim Bray who arranged the sponsorship wrote about why Sun would do this:

Ruby isn’t finished. It’s a great substrate for Rails, it’s immensely useful for building all sorts of things, but it’s not fast enough. I agree with Avi Bryant’s argument that a language isn’t finished until it’s fast enough to extend itself. Frankly, none of the language enhancements proposed for Ruby 2.0 make my heart go pitter-patter. But give me a Ruby with performance as good as a really good Smalltalk VM, and the space of things for which you need statically-typed languages shrinks to a really uninteresting size.

Except for, nobody including me is smart enough to predict which of the Ruby.next implementations is going to have that performance mojo. So, it seems like the only reasonable thing is to bet on all of ’em. One thing that makes this easy is that all the teams get along with each other; a natural outgrowth of Ruby culture, and something from which we can all learn.

Ezra Zygmuntowicz and EngineYard think that Rubinius is important enough to have started hiring Rubinius developers.

I’m really stoked about this. I think rubinius has so much potential that I am really happy to be able to support it. Starting next month Evan Phoenix is going to be working here at EY half time on ey tools and such and half time on rubinius.

The sprint itself went very well. Evan Phoenix, Wilson Bilkovich, and Brian Ford (the core rubinius developers) met with Charlie Nutter (one of the core JRuby developers) for some intensive Rubinius hacking. Brian and Wilson have both written about the experience. Evan joined them in an interview. In the interview, Evan talked about the goals and outcome of the sprint:

[We wanted] to see how we rubinius work would progress in this kind of environment. I was extremely pleased how it went. The 4 of us really tackled things well, and working in a collaborative atmosphere really sped things up. I was also happy to be right there to transfer knowledge of some of the interior of the VM to other developers. That knowledge is more difficult to grasp than almost anything else in rubinius, but probably the most important.