Last week in Denver, the Rubinius guys had a coding sprint; read about it in Brian Ford’s Rubinius sprint retrospective and Wilson Bilkovich’s Implementing define_method. We at Sun supported it by covering the travel costs (well, we will as soon as I get the paperwork, guys) and by sending Charles Nutter along for a day. Looks like they got some good stuff done. Rubinius is an attempt to build the next-gen Ruby implementation. Which is happening in parallel with the “official” Ruby 1.9 work in Japan and the JRuby project. [Update: Pat Eyler interviews the sprinters.]

Basically, we’re supporting all of them. Along with giving Rubinius a hand, we employ half the JRuby committers, we’ve donated a server to Matz’s gang, and (I hope to be able to announce soon) we’re going to be giving the Japanese side some other support.

Why are we doing this? Because, in my view, 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.