Last week, I had the chance to talk with Evan Phoenix, a Software Architect with Engine Yard, which specializes in hosting sites that use Ruby on Rails. Engine Yard’s focus is on sites that have more upscale needs, including a high level of staff support for deployment and application debugging and high-usage scenarios. As a result, Engine Yard requires a Ruby VM with better performance than what is currently available — and this is just what Evan has been working on. His current project is a Ruby VM named Rubinius. He was generous enough to provide me with some insight into the project, which I thought you might find interesting.

Rubinius: Features and goals

The Rubinius project initially began as a personal, “for fun” project for Evan; now Engine Yard has picked it up to meet its performance needs. Evan hopes to be able to get features into upcoming releases that will make life easier for Engine Yard.

Currently, the release is nearly completely compliant with the Ruby spec; once that is finished, they will begin adding on more “goodies” to Rubinius. One new feature that is already included is the exposure of significantly more internal information than the standard Ruby interpreter provides. This allows the programmer access to better debugging hooks, as well as a performing reflection of the runtime state of affairs, which is quite handy in an object-oriented, dynamic programming language like Ruby.

Evan and I did not go into deep technical details about the project, but he did give me some good insight into the overall picture. A notable item is that Rubinius is written in Ruby. A language that can compile or interpret itself is often a milestone marker for the language, so it is good to see Ruby getting to this point. It also means that the people who will be able to contribute to Rubinius are the people most interested in it: Ruby developers. Evan pointed out that this makes it a great project for Ruby developers who want to be more involved in the community, but may have felt shut out because the work has always been in C/C++.

One of the project’s goals is to have a better garbage collector (Evan mentioned Java’s garbage collector as an example of what they are striving for). They also want Rubinius to get better performance, which is especially important in Engine Yard’s environment, and should be of interest to anyone working on Ruby applications that have a need for scalability. Engine Yard is also working to build more intelligence into the system, such as adapting to a piece of code and optimizing on-the-fly to it. Currently, Rubinius is only available on *Nix, but they are hoping to be able to release a Windows version soon.

Ruby: Developers’ enthusiasm is contagious

I am finding the Ruby development community to be incredibly vibrant, enthusiastic, and attractive. Every time I talk to someone about it — whether it is Evan, Scott Abel of Spiceworks, or anyone else using Ruby in production work or involved in the community — I get the urge to learn it. I have not dealt with a group of developers this enthusiastic about their language of choice since I mostly dropped out of the Perl world. I have been struggling for some time to find a formal business reason to justify doing some work in Ruby (even if I have to use IronRuby).

If you are a Ruby developer, you definitely should check out Rubinius, and see if you’d be interested in using it and/or contributing to it.


Disclosure of Justin’s industry affiliations: Justin James has a working arrangement with Microsoft to write an article for MSDN Magazine.

Related TechRepublic resources


Get weekly development tips in your inbox
Keep your developer skills sharp by signing up for TechRepublic’s free Web Developer newsletter, delivered each Tuesday. Automatically subscribe today!