in which the events of and surrounding cabooseconf are recapitulated

Over the weekend I spent some time with thousands of geeks in Portland as RailsConf was held at the Oregon Convention Center. While I always enjoy these kinds of events immensely, I usually have just as much fun with the socializing aspect as I do with the actual conference material. So this year I decided just to head over to CabooseConf and only attend the "hallway track" at the main event.

As usual, Portland was the ideal host city for the conference. It's beautifully green in a way that makes it simply refreshing to walk through. The convenience of getting around would have been better for me personally if I had thought to book a hotel closer to the Max line, but no US city that I've been to does visitor-friendly better than Portland. It came as a major disappointment to hear that it might head to the wastelands of Nevada next year—yuck.

CabooseConf was a really low-key string of hackfests put on by the folks at ENTP. Even if it didn't seem too lively at first glance, the room kept humming with a quiet energy of hackers working on big ideas. Getting that many bright people together is bound to spark all the right kinds of conversations.

I greatly enjoyed finally getting to meet JD, the other main Bus Scheme contributor and welcoming the enthusiastic Jack Danger Canty to the team. I had hoped to start adding support for macros to Bus Scheme, but the work I started in that direction revealed some weaknesses deep in the implementation. The code has much more internal consistency now (we changed a huge amount of code over from using Arrays to internally represent code to using Lists) and is pretty solid. Jack has actually deployed the first Bus Scheme web app in the wild as his home page, which is a noteworthy milestone. I've begun support for macros but am still a ways away from getting that totally ready. Scheme macros are fairly different from Common Lisp or Elisp's version, so it's taken some learning.

If you've read anything about RailsConf this year, you've doubtless heard a lot of people excited about MagLev, a new upcoming Ruby implementation. Since I didn't go to any of the talks I didn't see the demo, but I've read enough to be skeptical. I know for a fact that the world of Smalltalk has a lot of amazing technology around it that would really benefit Rubyists. But the way people go on about MagLev like it's going to solve everyone's problems with its 60x performance boost is really short-sighted. The obvious bit is that they haven't given anyone any reason to think they've got a system that supports Ruby's object model and execution semantics on anything other than a very superficial level. It's easy to optimize microbenchmarks to get 60x speed boosts like MagLev claims if you don't allow for the dynamicity of Ruby, and MagLev has so far made no claims towards being able to run (let alone pass) any of the Ruby specs.

But this is really just a side-effect of the real problem: There is absolutely no transparency into the development cycle of MagLev. We're seeing a group of engineers who are grounded in a 1980's mindset of "let's demo this technology we're working on to a bunch of potential customers" rather than entering into the Ruby community and approaching us as a group of hackers. We don't value slick demos and impressive statistics; we value code and code alone. We have learned the mistakes of single-vendor reliance, some of us by observation and some of us by painful experience. Even Sun learned that people won't put up with it. No—even Microsoft isn't daring to suggest that you use a Ruby implementation that ties you into their proprietary software stack.

The really crazy thing about the whole issue is that it reveals an idea that somehow it's difficult to make money with a really excellent piece of free software. It blows my mind that people still think this in AD 2008. People will trip over themselves to get a good place in line to throw buckets of cash at you if you can provide them with an open-source software stack that comes anywhere near the 8x-60x speedup that MagLev has implied is possible. It grows even more obvious when you think about the fact that the other big win with MagLev is the OODB, something that very few Rubyists have any idea how to deal with. And Gemstone has the expertise needed to port our Rails applications from this hacky object-relational mapping model to their vastly more elegant and scalable paradigm. It would be hard for them not to make money in a situation where MagLev came under a reasonable Free license.

« 2008-06-04T09:32:42Z »

josh susser – 2008-06-04T22:28:48Z: I'm sorry I didn't get over to CabooseConf during the peak days. It sounds like it was a great affair. I'm really looking forward to it being integrated into the main conf venue next year. Woot. I agree with much of what you say about MagLev. I still think it's the most exciting thing I saw at the conf, but I do think it's fair to be skeptical. However, Gemstone has been around a long time and their VM technology is quite solid. I'd lay odds they'll be able to deliver a high-performance VM, though I doubt we'll see 100x performance like some of those microbenchmarks they trotted out. The OODB technology is more interesting to me, though there are many technical challenges to be solved (schema migration, anyone?). Your thoughts on closed vs open are representative of many rubyists and open source hackers, and there's something to them. But I also think that there isn't much to worry about in terms of abusive practices or lock-in. If this takes off, I'd expect it to spur some open source innovation and Gemstone will either open source things or be trounced by someone else who does. Even Java is open now, right? I think the main problem is cultural, and that the open source mindset is a huge shift for Gemstone. It's probably a good sign that they showed up at the conf and did the session and mixer. Get a dialog going, who knows what might happen. (cue Polyanna theme music...)
alexvollmer – 2008-06-05T20:32:04Z: I too will be greatly disappointed if they follow through on Chad Fowler's threat to move RailsConf to Vegas. Boo hiss.
Yossef – 2008-06-06T07:31:54Z: I remember seeing a thread on ruby-talk started by someone posting the parse tree from some simple code like `x + y` and wondering what all the message passing was about. That's so slow and inefficient! Just make it add the numbers and you're done, right? Look how much faster it can be!
Yeah, it's not hard to make something as fast as C you're only concerned with C's semantics.
Really, I'm just posting this because I want the '2 comments' not to be a lie, but I imagine that's wishful thinking.