Rubinius Surges Ahead

Posted by Obie Fernandez on Dec 07, 2006 12:43 AM

Community

Ruby

Topics

Open Source ,

Dynamic Languages

Tags

Rubinius

Geoff Grosenbach, the popular (second only to DHH himself) host of the Ruby on Rails podcast and the producer of the Peepcode series of instructional videos, has upped the ante in the race to achieve a usable next-generation Ruby runtime. This week Geoff announced that he is backing Evan Phoenix, lead developer of the open-source Rubinius Project to the tune of 1000 USD.

After hearing a RubyConf presentation from Seattle.rb member Evan Phoenix I had wanted to find a way to help. It’s a project to write a fast, maintainable, Ruby 1.8-compatible interpreter. Last night I learned that Evan is between jobs and won’t start his next job until January. This seemed like a fantastic opportunity to support the Rubinius Project financially and give him a reason to spend the month of December working on it.

Not only that, Geoff is also encouraging other members of the community to donate money to Evan also, as a way to get him to dedicate more full-time work to the project.

The support seems warranted, particularly since Rubinius, at least for the time-being is making rapid progress. Commenting in Geoff's blog, well-known Rubyist Wilson Bilkovich said, "Continuations, regular expressions, Miniunit, Bignums, and numerous control structures like ‘retry’, ‘redo’, ‘break’, etc were all added in the last week."

The design approach for Rubinius borrows many concepts from Smalltalk and is markedly different from other competing projects. For instance, there has been considerable debate in the community about the future of continuations, in no small part due to their poor implementation in Ruby 1.8 and comments by Matz to the effect that he will remove them entirely from Ruby 2.0. In contrast, read Evan's comments about implementing continuations in Rubinius:

They’re [continuations] under fire right now in the ruby community as to whether they’re a feature that implementations need to support. Rather than wait for the dust to clear, I went through the motions of implementing them in rubinius. It was amazingly simple actually. It required some debugging to get it correct, but all in all there wasn’t actually all that much code, just a primitive VM method to manually activate a method context (aka a stack frame). Having method context’s be first class objects is what made it easy, and it’s again validated my decision to make everything possible first class.

In a blog post defending his decision to accept monetary donations, Evan explains his motivations and outlook. While walking a very thin tightrope by trying not to criticize Matz, Evan ends up revealing some interesting opinions about the future of Ruby, and its "official" next-generation runtime, YARV:

I’m not putting my money/time into YARV because I don’t believe it’s the right way to accomplish the goals. (...) YARV may or may not see the light of day. It’s been in development for 2+ years and while it’s getting close, matz has not committed to it for at the very least another 2 years. So, if we wait for YARV, the community is still a long ways away from a modern VM. Plus, I believe that YARV has a lot of the same problems the current interpreter has. It’s filled with very complicated, undocumented structure that makes working on the core quite difficult.

I believe that the future of the ruby core is in a simple core and a simple architecture that is easy to modify. Rubinius goes to vast lengths to keep the core parts as simple as possible. Because in the end, it shouldn’t just be me and a few core developers who can dive into the core and change things. I want it to grow and flourish in the hands of everyone, and I believe the only way to do that is to build in that virtue from the beginning.

 You can take a stroll through the Rubinius codebase for yourself by browsing the svn repository.

1. Back to top

   Rubinius uses Valgrind too

   Dec 7, 2006 9:53 AM by Pat Eyler

   Another nice feature of the rubinius development effort is that they're using Valgrind from the get go to make sure they avoid memory leaks (a nagging issue in Ruby). This is going to make a lot of people happy, since using Valgrind on Ruby is next to impossible at this point.

   Reply

• Older >