IronRuby: Only Resting?

By now everyone and his twitter account has heard the news about Jimmy Schementi.  There’s also the obvious back and forth about whether IronRuby can now be considered dead.  Most of it has been of the form of “the community will decide” versus “without Microsoft support, it’s a dodo”.

Let me start my own take on this with my own experiences of IronRuby.  I’ve been concentrating on using it as a testing platform for C# code, with some success.  Here’s my take on the current state of affairs:

IronRuby 1.0 is a relatively good implementation of Ruby 1.8.  Since the community at large seems to be having serious trouble moving to 1.9, a hiccup in IronRuby’s progress wouldn’t seem to be that big a deal.  However, that’s to ignore some huge obstacles.

As I’ve already touched upon, Cucumber may have worked a a year ago, but it doesn’t work now.  Multiply this by the number of native packages for Ruby and you have a serious problem.  However, the community support isn’t the only issue.  The performance while debugging C# code round-tripping to IronRuby code is appalling.  Borderline unusable.  Now, I don’t need editor support for IronRuby, I’m a big boy and can find my own text editor.  But being unable to debug C# in a timely fashion?

In short, if you’re using IronRuby right now, you’re going to have problems calling into a C# extension and you’re going to have trouble using a gem as well.  For an early adopter that’s not a problem.  But if this is the finished product, we’ve got a problem on our hands.  Ironically, I didn’t want to just use it as a platform for rails and leave .NET behind.  I wanted to use it to make my C# code better.

Oh yes, and RSpec absolutely rocks.

A Much, Much Bigger Picture

I sincerely believe that the .NET runtime is, at a technical level, hands down superior to the JVM, MRI or CPython runtimes.  But the community (of which I am a part) simply cannot compete with Java, Ruby or Python.  They’ve got better tools, more ideas, faster delivery cycles and more people.  And here I’m only talking about language/platform communities.  Node.js is really exciting, there’s 100 versions of NoSQL that are worth investigating.

I can’t really fault Karl Seguin’s logic, but this is the logic of the SKU, which I’ve already had a rant about.  This is killing Windows (not .NET, Windows) as a development platform and no-one seems to be noticing.  I basically have two choices: ditch Windows as a platform, or make do with inferior solutions for web applications, database server, testing suites and so on.  It’s not quite as aggressive as Steve Job’s rewriting the App Store rules to dictate how I program, but it’s still not a pleasant choice.

The Next Big Language

All of this is ignoring the elephant in the corner: JavaScript.  Microsoft’s DLR strategy was always fundamentally flawed in not addressing JavaScript.  It seems that large numbers of people at Microsoft just don’t really like or understand the language, which has lead to them spending years trying to turn it into something that it isn’t.  It sounds like they’ve finally got a clue on IE9, but does this approach have anything even to do with .NET.  This means that not only have they missed the Ruby and Python waves, they’re just about to miss the next one.  Node is turning JavaScript into a serious out-of-browser development language at a point where Microsoft appears to have finally given up on the idea.

You mustn’t read too much into one blog post, but you’ve got to question Microsoft’s game plan.  Because right at the moment, all of their strategies seem to be about trying to lock people into a crumbling platform, rather than trying to create the platform that everyone wants to use.  The real kicker of it is: .NET really is a great platform.  I don’t want to stop using it, I want it to actually live up to its ambition and let me use tools from any platform on mine.

NOTES:  The puzzle picture is by Lynette Cook, the elephant is by Tom Claytor.  I don’t know who’s the artist behind the parrot picture, but I got it from this gag post.