ronin coder

There’s been a lot of breathless blog coverage of MagLev, the new Ruby-on-a-Smalltalk-VM implementation from Avi Bryant (of Seaside and DabbleDB fame) and the Smalltalk wizards at Gemstone. They did a demo a RailsConf 2008 which showed insane performance gains over MRI, (like 10x to 100x, depending on the micro-benchmark chosen) and since the OOBMS is baked-in, they got to casually toss around numbers like “17 Petabytes.”

Let me say this upfront: I have a lot of respect for the guys over at Gemstone. They have some serious pedigree in the Smalltalk world, and they’ve done a good job of spinning that expertise into continuing business in the heavy-duty enterprise space. Ruby and Smalltalk obviously have a lot in common at the language level, so I can see the appeal of building a next-gen Ruby runtime atop a stable, tested Smalltalk VM.

However, I think that there are a couple of red flags worth noting here. First, as quite effectively laid out by Charles Nutter of the JRuby team, executing Ruby code in a mode fully-compatible with MRI is very much not the same thing as being able to run some programs written in Ruby syntax. The surface syntax of a language is only a small part of its overall semantics, and evaluation is much more complicated than parsing.

Avi and the Gemstone team are very bright cookies, and I don’t doubt that they’ll eventually be able to hit whatever level of Ruby compatibility they set out to achieve. If that means running Rails, I have little doubt they’ll be able to run Rails. If that means 100% compliance with the growing corpus of Ruby specs being developed by the other runtime projects, I have little doubt they’ll hit that milestone, too. There may be some impact on performance, but overall, I would be shocked if a solid, mature JIT-able VM like Gemstone’s wasn’t running circles around MRI.

Regardless, I personally am still unlikely to use MagLev in a more than cursory fashion, or recommend its use to others. I’ve worked in teams whose core product was dependent on the availability — permission, even — of a proprietary tools vendor[1]. Smalltalk and Common Lisp toolchains (the latter being the arena in which I have more direct experience) have both had this problem for decades: the best implementations are closed-source, costly, (to the tune of several thousand dollars per developer, plus hefty runtime royalties and/or deployment licenses[2]) and tend to encourage platform lock-in with all kind of alluring features like fast, large-scale object stores that are 100% incompatible with any other language or development tools.

In my opinion, proprietary runtime stacks are also pretty much incompatible with open source, at least in the sense of “anyone being able to contribute to the project.” While the core language features may be portable between MagLev, MRI, JRuby, Rubinius, IronRuby, FooRuby, RubyOnAStick, et. al., the object database API most definitely will not be.

As a language geek, I’m definitely curious to see where these guys can take MagLev. Personally, though, I would have been a lot more excited to see Ruby on the Squeak VM or GNU Smalltalk, if the point was simply to show what Smalltalk runtimes can bring to the table for Ruby programmers. By tying the first Ruby-on-Smalltalk implementation to a proprietary toolchain, Avi & Co. may have doomed it to occupying the same edge niche that Smalltalk and Common Lisp vendors have been forced into for the last 30 years.

(Edit: Avi himself has now weighed in with a brief recap of the presentation, including some clarification of the release and licensing plans. I don’t necessarily think that anything he said really argues to the points I make here, but it’s worth a read.)