Alex Payne

Writer, backer, erstwhile technologist.

RubyConf 2007, Day 2: Rubinius 1.0

The second day of RubyConf began with a grip of talks on alternate Ruby VMs: IronPython (for the .NET platform), JRuby (for Java), and lastly Rubinius (for great justice). Sheepishly, admit that I slept through the first two; neither .NET nor Java are relevant to my interests.

Rubinius, however, is extremely relevant to my interets. Evan Phoenix — runner up to Havoc Pennington in the “best name in Open Source software” competition and the project’s founder — let the science drop about the project’s pending 1.0 release.

Phoenix has developed a signature presenting style: fast, direct, and punctuated by amusing, colorful slides. He opens with a brief history of Rubinius’ founding and its origins at a previous RubyConf. Rubinius has ancestors in Smalltalk’s implementation and borrows freely from “crazy compsci papers”. At present, the project boasts generational garbage collection, stackless execution, JAR-style packaging, pre-compiled files, and a host of other exciting features.

The most critical part of Rubinius’ implementation is that a majority of it is written in Ruby. Rather than being purely C, C#, or Java, Rubinius has only enough C to bootstrap the remainder of the language’s core being written in Ruby. Phoenix claims that Rubinius is “Ruby for Ruby programmers.”

Currently, Rubinius is beating the standard 1.8.x Ruby implementation in 24 of 31 of the YARV benchmarks. Beyond that, Phoenix isn’t interested in talking about performance at this point in time, as the implementation’s speed is highly variable at present.

Rubinius isn’t done yet. By way of explanation, Phoenix mentions that the project is learning from its mistakes and “optimizing for fun”. Community is stressed as an important part of the project’s evolution. Rubinius now boasts 57 committers, of whom 17 have committed frequently. The project is eager to hand out commit rights to anyone who submits a single patch — an extremely liberal open source project management style.

Questions

First up, a hardball: should Rubinius replace MRI (Matz’s Ruby interpreter, the standard implementation of the language)? Phoenix suggests that’s up to the ecosystem/community to decide what should be the standard.

Can you swap in another kernel? Yes. The project has been designed for modularity.

Are there more things you can override? By way of answer, Phoenix mentions that the entire compiler is written in Ruby, and that it’s a “malleable system that can be changed over time.” Compiler flags are available to change what decisions the compiler makes.

How small can the kernel be? The long-term goal is to have zero lines of C code by following some of the self-hosting strategies of Squeak’s VM.

Concerns about incompatibilities? “We try to be as compatible as we can.”

Hard numbers about the project’s status and compatibility? “We’re down to 500 failing specs. While MRI is the main compatibility target, ”we’re trying to be as agnostic as possible with the specs.” The specs are written in a “mini-RSpec” implementation that’s intended to be syntax-compatible with RSpec.

What about the backtrace format? Phoenix shows a trace that’s smart about showing the developer where the program actually died, even though the failure involved a method call that bridged two classes. Rubinius will also be able to provide backtraces for segfaults in C extensions.

What about NextObject? Haven’t figured out a good way to do this yet.

Continuations? Rubinius has first-class method contexts, and Phoenix demos its use. “A continuation is just the ability to save a point in time and go back to it”. So, in Rubinius, you save a MethodContext and go back to it to implement continuations.

Will MethodContext be serializable? Yes, but nobody has written it yet.