Monday, May 21, 2007

Avi Bryant's RailsConf Keynote: Ruby Can Become Very Fast, And The Tools To Support It Can Become Incredibly Powerful

Got two comments about this, one of frustration at missing the keynote, one requesting more detail, so, here we go.

Avi basically said:

I'm from the future, I know how this story ends. All the people who are saying you can't implement Ruby on a fast virtual machine are wrong. That machine already exists today, it's called Gemstone, and it could certainly be adapted to Ruby. It runs Smalltalk, and Ruby essentially is Smalltalk. So adapting it to run Ruby is absolutely within the realm of the possible.

He also pointed out that the Strongtalk Smalltalk VM had incredible performance, although Evan Weaver later told me that the Strongtalk VM was never actually finished. The Strongtalk site confirms this, although I get the feeling that they did get most of the heavy lifting out of the way.

Anyway - going back to the summary - Avi was also saying that since Ruby is so similar to Smalltalk, and Smalltalk has unparalleled GUI and IDE support, it's pretty easy to see a future where all these tool vendors and IDE creators really come up with something incredible by simply going back to Smalltalk and mining it for all its lost riches. There was a real Raiders of the Lost Ark vibe to Avi's talk, or a Tomb Raider (the game) vibe, because he knew where to find this stuff, and he knew it could be repurposed, so it really is there, and all we have to do is go and get it. There's very fast VM technology out there which is totally capable of handling Ruby's dynamic features, because it can handle Smalltalk's dynamic features, which are exactly the same features, and it's absolutely possible to build a fully graphical environment for such a language, because that's what Smalltalk is.

He specifically highlighted comments from Tim Bray, who had said that building a competitive VM for Ruby could never really happen, because of specific dynamic features of Ruby. He also got a comment from somebody in the audience who had worked on a Smalltalk VM, and who said that enabling that dynamicity was a hard thing to do. The person was wearing a Powerset T-shirt, so I think it was Josh Susser, but I don't know for sure. It's actually a really interesting question, but there are so many implementations of Smalltalk that I think Avi's point had to have had some strength to it. Now that I think about it, though, I really wish I'd found Josh and asked him about that. I also had been hoping to meet Avi, but couldn't find him after the presentation.

It was a pretty exciting talk; I just wish there had been people from Gemstone there to hear it. There were a lot of cameras and mixing boards at RailsConf, so I think there's a very reasonable chance that the keynotes will become podcasts, including video. Very worth the download if that happens.


  1. About Strongtalk it kinda depends how you define finished. They are/were certainly at the point where they have/had working code and a running Smalltalk image. You can download it an run it. It's just that a lot is missing for a real Smalltalk system (even parts of the numeric tower are not implemented).

    I wouldn't say the IDE support of Smalltalk is unparalleled. Eclipse has far more advanced and complete refactoring support. Now I will get flamed for saying this, but do an extract method refactoring in Smalltalk without pretty printing the method and then come back. Don't even get me started about scoping renaming method refactorings.

  2. Of course, why wait, Smalltalk already exists today, just use it. No need to wait for Ruby to re-implement it.

  3. Giles, the GemStone folks were not completely unaware of Avi's message. We're in the process of porting Seaside to GemStone (see for details) and we happened to talk to Avi on Friday, before his talk. He did mention that he thought a GemStone-based ruby vm would be a good thing. He told us that he'd mention GemStone in his talk, but no other details.

    Frankly, we had not thought about a GemStone-based ruby vm prior to our meeting Friday, but the combination of our vm and OO persistence expertise applied to ruby could be interesting.

  4. I work for GemStone and was very pleased to hear Avi's talk. Both Smalltalk and Ruby are lovely languages and I am hoping that GemStone will be able to apply its collective knowledge to the evolution and adoption of Ruby and Rails.

  5. Hey Dale and Alan - that's awesome! If GemStone puts out a Ruby VM with OODB persistence, so people can just skip using SQL entirely, I think that will be AWESOME. The whole idea of using SQL as a persistent store for Web apps is flawed in the first place, Evan Weaver spoke about this at RailsConf, I'm going to do a writeup on that sometime soon. Anyway, just for perspective, Rails is getting bigger and bigger every day, and there's a lot of spillover into other areas, since the success of Rails gives Ruby programmers leverage to bring Ruby into other contexts as well.

    Philippe - well, the finished thing, yeah, it's even on their site, like I said in the post, it looks as if the heavy lifting is complete but there's still lots left to do. The unparalleled thing, well, honestly I talk way too much about Smalltalk, I don't code in it half enough to justify all this talking, but maybe if you switch unparalleled support to unparalleled integration my statement works after all.

    And if you're just talking about Web applications, there isn't anything as cool as being able to edit your Web app from within your Web app. Squeak might not have a refactoring browser as cool as Eclipse, but the IDE in Seaside is absolutely not matched anywhere in the Web world that I'm aware of. Avi himself said he doesn't even use that feature much, but it is so cool! It's like having an ejector seat in your car. You don't have to use it every day for it to be cool.

    Ramon - fortunately I have to talk about Seaside and Rails at OSCON in July, so I absolutely have to spend some time between now and then doing some coding in it. Whenever I pop into Squeak I always enjoy it but I've never built anything particularly remarkable in it. I can really only barely even claim to know it. Smalltalk the language is very easy to learn, but the library and idioms I still haven't got.

    Expect more Smalltalk content in the near future, though, nested in with post-RailsConf brain-fizz etc. I think Seaside and Prototype/Scriptaculous are the two coolest things going on in the Web right now. (By the way, I was following along with your latest screencast on the plane.)

    Nima - you're welcome!

  6. Yes, that was me piping up in the Powerset shirt. I had a chat with Avi afterward and got some more details about what he was thinking. It makes sense to me at a high level - the Smalltalk VM provides enough in the language kernel to let the compiler create objects that supply all the features of Ruby. What I'm not convinced of yet is that doing that is the optimal approach, or will have suitable performance. It's possible that that kind of hackery might be so complex that it would negate the performance benefit of that wonderfully optimized VM technology. But Avi's been thinking about this a lot longer than I have so maybe he's right. So far I'm a fan of Rubinius.

  7. I don't know much about compilers, interpreters, and VMs, but Rubinius is definitely a promising project. There's a neat interview with Evan Phoenix, creator of Rubinius, where he talks a little bit about the similarities between Ruby and Smalltalk, too (topically enough).

  8. The Self project was finished and Self had excellent performance (at least within 50% of optimized compiled C code).

    For those who don't know, Self is a sort of simplified Smalltalk and was one of the first (if not the first?) prototype based languages.

    There are quite a few articles on Sun's site (they funded Self) at

    One can always implement a class-based system in a prototype-based system, so there is absolutely no question about letting Ruby achieve this performance.

    So Ruby (and Python and Perl...) can run quite fast, unless you consider 50%+ of C's speed to be slow.

  9. the problem is that evidently the ruby community does not give a shit about performance.

  10. 50%+ of C performance is terrible. Perl is usually at or above C levels, and Python is only a little bit behind.

    Parrot demonstrated this very clearly to the Python guys, back in the day. The Parrot (optimized next-gen VM) guys said that it would be twice as fast as native Python. The Python guys said 'haha no way we are super optimizers and we wrote it in C'. So then an unoptimized incomplete Parrot build with a rudimentary python implementation beat them by 2-3x on a bunch of tests the Python guys specifically chose to try to win.

  11. Why bother with Ruby at all? Why not use Smalltalk instead? It's more powerful, has better implementations and has a simpler syntax. AFAICS, Ruby is just Smalltalk corrupted by Perl.

  12. Has the rails "community" heard of this really new fantastic phascinating.. phantabaulous, dare I ssay pewwteefool technology call MICROPHONEs and recording equipment and this newfangled thingy call mp3's or something?

    What bothers one more than the craven and cynically commercial attitudes of the rails bigwigs is the spineless acquiescent nature of the horde of fanboys who take every abuse as if it is manna from heaven!..

    Never fear, the mp3's of the keynotes will be available for a "reasonable" price of just a 100 dollars a download...


  13. "50%+ of C performance is terrible. Perl is usually at or above C levels, and Python is only a little bit behind."

    What? In a number of those tests, C is more than two orders of magnitude faster.


Note: Only a member of this blog may post a comment.