Chad Fowler nails it with his summary of MagLev.

Like Chad, I think MagLev’s initial performance numbers will hold up. It’s possible that as it matures it will get slower, but it could get a lot slower than it is now and still easily be the fastest Ruby VM around.

And I agree with Chad that it might even get faster. I’ve also spent some time investigating how to make Ruby run on a Smalltalk VM, and it’s a really close fit. During the presentation at RailsConf, either Avi or the Gemstone guys revealed that they had modified their Smalltalk VM by adding two new bytecodes aimed at Ruby. I’ll go so far as to speculate: it’s likely that those two bytecodes deal with variadic methods and creation/lookup of dynamic instance variables. It sounds as though the core Ruby language is nearly complete on top of that base, so it’s easy to imagine that the early, hurried implementation of those two new bytecodes could be optimized further. And some of the Ruby features that have hurt JRuby’s performance will be no problem on a Smalltalk VM—ObjectSpace, for example, can work using the same facilities that Smalltalk’s development tools use today.

The persistence story is amazing. Avi and the team at Gemstone plan to implement an interface that is similar to ActiveRecord, but cleaner, since the object/relational impedance mismatch no longer applies.

Finally, there’s the question of licensing. I’ll be shocked if MagLev is open-source, but I think there’s room for a proprietary Ruby implementation. The team has committed to complying with RubySpec, which means I’m not very worried about compatibility. Most Ruby projects won’t need MagLev, but the ones that do will gladly pay for a top-notch, supercharged implementation with great scalability and persistence stories.

I’m definitely looking forward to hearing more about MagLev over the next few months.

Because I was pressed for time yesterday, I ended my blog on Ruby VMs with a little teaser about other possibilities: "And there is still room for serious creativity there. I’ll write more about that soon." About two hours later, Avi Bryant posted essentially the same thing I was going to say.

Avi has blogged before about the idea of implementing Ruby on an existing, fast Smalltalk VM (the object models of the two languages are very, very close; the biggest hurdle would be Ruby’s richer method argument handling).

But, as Avi points out, the open-source availability of Strongtalk, including the VM implementation, is a big development. Although it’s now ten-year-old technology, Strongtalk nevertheless represents the state of the art in dynamic language implementation. Strongtalks basic principles of operation have been widely known for years (although apparently not by Joel), but actual implementations of those ideas have all been in proprietary products. (The Hotspot source is available, but not as widely as a true open-source products.) For OSS developers who want to learn, the closest they could get to a cutting-edge dynamic language implementation has been Self. But although the techniques in Strongtalk originated in Self, the Strongtalk team took them a lot farther.

Sun’s HotSpot VM for Java already incorporates these techniques, so JRuby is already on track to take advantage of them. I don’t know that much about the CLR, but it wouldn’t surprise me to learn that it uses similar ideas, which bodes well for IronPython and an eventual Ruby implementation for the CLR. But there’s still a performance limitation imposed by the mismatch between object models, and the unavoidable mapping layer that implements one atop the other.

Mr. Malsky, I predict that in three years, Ruby will have performance rivaling Strongtalk’s — whether by someone adapting Strongtalk itself to run Ruby, or by mining it for techniques that can be rolled into YARV or some other VM project.

(Well, maybe three years is a bit optimistic. But I can hope.)

Last year at FOSCON (and the next day at OSCON), _why showed the first animated installments of his "Least Surprised" cartoons, to the delight of all present. In one of them, Time.now.is_a? MagicTime, Malsky asked his audience to imagine what Ruby will be like in three years. The first suggestion? "Maybe we’ll have our own virtual machine by then." Malsky was appalled. "No, no! Come on, guys! Three years? Ruby will have ten virtual machines built inside every metaclass by then. Be creative!"

For several of us sitting in the back, "ten virtual machines built inside every metaclass" was one of the biggest laugh lines of the evening.

Of course, it’s still absurd — but maybe only by two or three orders of magnitude instead of four. I’m amazed at what’s happening in the world of Ruby and high-performance virtual machines. I’m personally aware of seven (!) projects to either build a Ruby VM or implement Ruby on an existing VM:

• Of course, there’s YARV.
• JRuby, which has been around for a long time as a Ruby interpreter, is starting to become a true bytecode compiler in the Jython style.
• There are no less than three projects to implement Ruby on the .Net CLR, building on the lessons of IronPython.
• The Cardinal project, to implement Ruby on Parrot, has been restarted by Kevin Tew. (And Parrot itself is making serious progress again, after some difficulties.)
• Finally, there’s a project underway to implement Ruby on Nicolas Cannasse’s Neko VM.

Naturally, there’ll be some winnowing of these options over time. But it seems clear that the Ruby community will end up with at least three solid VM options: YARV, JRuby and some variety of Ruby on the CLR. The core Ruby developers are strongly committed to YARV. The CLR version is too important not to do (and to my mind, last week’s announcement of IronPython 1.0, still as an open source project, makes a mature Ruby implementation on the CLR even more likely). And of course, Sun has now hired the two main JRuby developers, throwing at least some of their weight behind that project.

Come on, guys! Three years? Ruby will have three virtual machines that’ll run in every kind of IT environment by then. Be creative!

(And there is still room for serious creativity there. I’ll write more about that soon.)

Woohoo!

Matz, Jim, and Why are all posting their OSCON presentation materials, which reminds me: here are the slides from my Metaprogramming Ruby talk.

(Oh, and I’ll add to Jim’s request for recordings or podcasts of Why’s performance. I’m particularly interested in a recording of "Setup and Install.rb" from Wednesday night’s FOSCON show.)

I'm back from OSCON 2005, and it was definitely a watershed event for Ruby. It was so great to be there, and to be a part of it. Ruby had a major presence every day of the conference.

Monday, both tutorials -- Dave Thomas' intro to Ruby, and David Heinemeier Hansson's intro to Rails -- were in the large tutorial room, and were packed. At Tuesday evening's extravaganza, David won the best hacker award, and Ruby got several nods in Damian Conway's unbelievably entertaining talk. Wednesday morning during the keynote, Tim O'Reilly discussed Ruby's small but growing share of the programming language book market, and speculated that Ruby might be "the Perl of Web 2.0."

David led off an eventful Thursday with a keynote on "The Secrets of Rails." All of Thursday's Ruby talks were standing-room only, and for three of them people were turned away because there was no place for them. Why's multimedia extravaganza was moved to a larger and more suitable room (thanks to Nat Torkington and the O'Reilly conference staff) and turned into the most memorable event of any conference I've ever seen.

Finally, Danny O'Brien's Friday "To Evil" keynote topped it all off, hilariously citing Ruby as a notable exception to Gandhi's famous quotation. Why? Because it went directly from "they ignore you" to "you win" in about three weeks.

Jokes aside, this week alone shows that Ruby has arrived.

The Ruby programming language is popping up everywhere this week. This is yet another in a series of indicators that something's brewing in the programming language space.

First, on Monday, Mike Loukides blogged about almost trying to learn Ruby. It's fun to see that he's at least planning to learn Ruby. At JavaOne a couple of years ago, Mike told me that O'Reilly really wasn't seeing much interest in Ruby. I replied that Ruby was still at the stage where the "thought leaders" were discovering it. By Tim O'Reilly's own heuristic, where the alpha geeks are going, others soon follow, and I predicted that Ruby would soon become more popular. I know that O'Reilly's seeing at least one indicator of increased Ruby interest, and maybe that's one reason Mike's planning to learn Ruby. This time, though, he decided he could get things done much faster using the tried-and-true Java way, and left his copy of PickAxe on the shelf.

Even though he decided not to actually try Ruby, he's questioning whether it's really useful. That's not an auspicious start for Ruby this week, I guess. But back to Mike later.

Today, there are a couple of other things. (And if you average Monday and Wednesday, you get Tuesday, see?) First, Howard Lewis Ship (author of the best Java web framework) showed up on ruby-talk and also posted a very favorable blog about his first Ruby program. I was elated to see this. Howard's expressed skepticism about dynamic languages to me at an NFJS conference, and was obliquely dismissive of Ruby in an earlier blog. But he's tried it, and was really impressed. I like the way he describes his first Ruby program: My trembling first journey into Ruby is [...] sloppy, doesn't report errors well, and took me too long to write (almost as long as it would have in Java!) His first program in a new language, and his criterion for "took too long to write" is that it took nearly as long as it would've taken in Java. Sounds like Howard caught a glimpse of how productive Ruby can be once you know it well.

And I have to say that Howard's first program is very nice! There are some things in it that an experienced Ruby developer would do differently, but it's definitely not "a Java program written in Ruby." Clearly Howard tried to learn not just the syntactic details of Ruby, but "the Ruby way." That's how we should all approach learning a new language.

So back to Mike Loukides. Maybe Ruby just isn't right for Mike. I'm on record saying that, in the debate between static and dynamic typing, perhaps there's not "one true way." But I'm convinced that for most tasks, dynamic languages are the way to go. (And I was a Java bigot for quite a while!) It's instructive to draw some lessons from the contrast between Mike's and Howard's experiences (and I'll throw in a few general thoughts, too):

• Anytime you have learned one programming language really well, you've reached a kind of "local maximum." To learn something different, even if it's ultimately more powerful, means stepping down from your current peak of familiarity and expertise and flailing around like a newbie on ice skates for a while. You won't see the benefits instantly. Howard describes his "trembling first journey," and that's how we can expect to feel the first time we try to write in a new programming language.
• Until your project is big enough that the gains start to outweigh the cost of the learning curve, the new language is bound to seem like a net loss. Howard's 292-line Ruby program is about the smallest project where you could expect the effort to pay off. (After all, it took almost as long as writing it in Java! :-) Mike's 25-line Java program is definitely too small.
• There are tradeoffs in languages, and Mike's right: not declaring your variables means that you don't have quite as much help debugging misspelled variable names. But the payoff comes in other ways, and not all of them have to do with writing the production code. Ruby does make writing the code easier, I think -- but it also makes it easier to write tests, and the code is easier to change.
• Not all "scripting languages" are alike. Mike implicitly criticizes the terseness of Perl (and also the "cryptic esthetic" of Perl culture, I suspect) when he lauds Java's readability. But Perl is different from Java in many ways, and Ruby only shares some of those characteristics with Perl. The Ruby language and the Ruby community place a big emphasis on readable code.

My intent isn't to bash Mike Loukides; he's a great guy, and he definitely has a point: the overriding criterion is getting the job done, and for his recent purposes learning a whole new language was probably overkill. (And besides, it would be the height of foolishness to bite one of the hands that invited me to Foo Camp.) But I do hope he'll make time to give Ruby a try, and give it a chance to prove itself on something reasonably sizable.

(Oh, and the other thing about Ruby that happened today? I noticed that, on the very cool website 43 Things, "Learn Ruby" is number four on the list of most popular things people would like to do. I wouldn't read too much into that; I learned about 43 Things through the Ruby community, and I suspect that high placement is an artifact of the way word of the site has spread. But it was still a pleasure to see.)

Steve Mallett reports in his blog that Ruby was the talk of OSCON this year. That's great news!

I helped Dave and James put together OSCON's Ruby track this year, so I'm really disappointed that I didn't get to attend the show. I really enjoyed it last year. But I'm very pleased at the Ruby track that resulted, and thrilled about Steve's assessment.

Of course, Dave had his "Ruby in a Day" tutorial, and Matz got to speak about the thinking that gives rise to Ruby. For OSCON, it was crucial to have a Ruby talk aimed at those with a Perl background, and Phil Tomson came through. And Rich Kilmer spoke about FreeRIDE, the Ruby IDE he's been developing. (FreeRIDE has a very interesting architecture, and I'm especially sorry I didn't get to see the talk.)

One of Ruby's real strengths, in my opinion, is its power for metaprogramming. Of course, many dynamic languages allow you to do such things, but in most languages the code for metaprogramming is almost otherworldly ... as soon as you start doing those kinds of things, your code becomes difficult for most people to understand. Metaprogramming in Ruby is unusually expressive and straightforward, and we found some great talks that showcase that capability. Michael Granger and DavidMcCorkhill started with a discussion of classes that adapt to the data they're representing. Chris Pine contributed an overview of the basic concepts behind Ruby's dynamic capabilities. And finally, Dave wrapped up with a talk I've been waiting to see for a year: a case study of a fascinating project he did last summer.

I think the next year will bring great things for Ruby. I think Mac programmers will continue to discover it, since it is bundled with Mac OS X. Ruby 1.8 is soon to be released, and no doubt it will be followed by new editions of the popular Ruby books. And if Steve's assessment of the mood at this year's OSCON is correct, there are a lot of Perl developers who see in Ruby something they're looking for.

Next year I hope to do more than help organize the OSCON Ruby track; I want to be there and contribute a talk of my own. Hopefully after the strong showing Ruby made this year, there will be more slots available for Ruby next year. A strong group of proposals can only help that effort, so start planning now!