IronRuby: Only Resting?

08 August 2010 10:55

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

picBullElephantTomClaytor

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.

Comments
Gravatar
# re: IronRuby: Only Resting?
Posted by Mauricio Scheffer on 09/10/2010 00:36
About Javascript and .NET: I don't think it's quite fair to say that Microsoft doesn't get Javascript... way before the DLR, there was JScript.NET, which was introduced back in 2000 (msdn.microsoft.com/en-us/library/ms974588.aspx) and it was pretty cool, it actually did type inference since it compiled to the CLR, but for some reason it never took off, maybe because nobody considered Javascript a cool language back then, or .net devs just didn't care. So I understand if Microsoft doesn't want to invest in developing Javascript *again*, only this time for the DLR. But they are contributing to jQuery, and also take a look at RxJS which fits quite nicely with node.js. And just as you said, JS gets a huge perf boost in IE9.
Also, there are a couple of interesting individual projects to get JS back in .net, e.g. IronJS (http://github.com/fholm/IronJS) and Node.net (http://github.com/dnewcome/Node.net)
Gravatar
# re: IronRuby: Only Resting?
Posted by Julian on 16/10/2010 09:34
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.
Something to add?

Talking sense? Talking rubbish? Something I'm missing? Let me know!

Fields denoted with a "*" are required.

 (will not be displayed)

 
Please add 2 and 8 and type the answer here:

Preview Your Comment