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”.

Nailed to its perch

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

Where exactly does office fit in here?

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.

Published by

Julian Birch

Full time dad, does a bit of coding on the side.

One thought on “IronRuby: Only Resting?”

  1. The problem with JScript.NET was… it wasn’t Javascript. It was a bit more like J#, where the syntax was a bit like Java but the semantics remained those of .NET. Take a look at this for a reminder of exactly how un-javascript it was.The IronRuby and IronPython approach was significantly different. There was a deliberate attempt to get the language working to the extent that libraries could run without porting. It’s hard because of both lanaguage’s obsession with native extensions, but nonetheless that was the aim.Admittedly, back in 2000 there were no significant code bases written in Javascript (except, ironically, for some ASP applications). These days, I’d say at a bare minimum, if you can’t run less.js, you’re not javascript.I agree IronJS and Node.NET, are interesting but I have to wonder what chance they have. This is absolutely no reflection on the individual projects or developers, but I think they’re going to have trouble achieving on their own what mozilla and google have strategically important teams doing.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s