It's About the API

Ok, at the risk of being almost timely, Zed's Rails Rant has inspired me to finish a point I've been wanting to make for a while now: Platforms (and languages too) are about the developer experience (API). Not the community, although that can help. Not the implementation -- that can be changed, redone, ported, etc.

What is nice about Ruby and Rails is that they're "fun" or "pleasant." In general, when programmers say this, what they mean is

1. Working with the language / API does not go against the grain of how their mind works. Since programmers have varied ways of thinking, simply avoiding an "against-the-grain" experience across a set of non-trivial cases is a real accomplishment. Ruby does this in spades, Rails almost as much once you get used to a particular "Rails way" of doing something.
2. It's at the right level of abstraction most of the time, when used in the kind of work for which it was intended. RoR is fabulous at this. It does the "super-high-level-language" thing when it reads your data schema, does :has_and_belongs_to_many, and makes a very sensible attempt to match URLs, actions, and views by default. It goes low-level by working with clean, trivial HTML, which is easy to write and debug by hand, while ignoring the temptation to autogen all sorts of decorated HTML/CSS/JS.
3. When you need to read the core sources or other people's code, it's not a terrifically painful experience that leaves you sitting there saying,"You've got to be kidding" over and over again.

Now, apart perhaps from a bit of #3, these are descriptions of a programmer's experience interacting with the language/platform/framework/tools.

They are API issues, not implementation issues. If the implementation is bad enough, the API experience will be overshadowed. But the developer experience sells the platform.

So... what about the MRI, and the Rails core team, and Mongrel and horrific perf issues, and all that?

The current state of affairs needs to be seen as a reference implementation. It shows off the specs under discussion, proves they can be implemented, provides all the right output to the definitive test suite, etc. Sun releases new Java APIs with a reference implementation. Some of those RIs have been good enough to use in production, some haven't. Sun hoped that third parties would create commercial implementations -- in some cases, this happened. Where an API was popular and important, a "real" version -- or several -- became available, based on market demand.

There are already a bunch of alternative implementations of Ruby either finished, or in the works. Rails has yet to see an alternative implementation, so far as I know, but it seems plausible that both open source (e.g., modify or redo the Rails code to provide multithreading support, etc. and run on top of JRuby) and proprietary (Rails as a set of ASP.Net assemblies) implementations will emerge.

When Java offered a great developer experience compared to the alternatives, it picked up adherents even when the adequate performance (heck, even existence) of various APIs was shaky. When .Net offered a great developer experience, it brought more shops into the Microsoft fold than 20 years of, shall we say, other approaches to gaining market share.

Some failed platforms suffered because of business issues (e.g., Delphi and C++ Builder), but most fail just because they don't do #1-3 above as well as the next guy on the block. My point is that Zed's rant is a bit beside the point, even if it's all true. Ruby and Rails have already accomplished the end of influencing industry thought and behavior in a broad kind of way. We'll need to be a little more patient (or make some serious contributions) before we get the followup implementations.