IronRuby In Steel?
So what’s the big deal with these metallic names anyhow? I’d like to think that Microsoft chose the name IronRuby as a homage to Ruby In Steel. After all, forms an essential part of Steel, but Steel is stronger - yes, I like the sound of that...! ;-)
A .NET Ruby compiler would certainly be a nice addition to have in our Visual Studio Ruby IDE - though, fear not, we have no plans to forsake the standard Ruby interpreter and/or virtual machine. In other words, Ruby In Steel will continue to support cross-platform Ruby and Rails development. The option of compiling to the CLR would make a useful additional feature but, when IronRuby finally appears, it is not our intention to concentrate on .NET development to the exclusion of all else.
But back to that name.... The truth is we can’t claim that Ruby In Steel inspired the IronRuby name. It is, in fact, named after the .NET version of Python, IronPython. The Python language is named after the old British comedy, Monty Python’s Flying Circus (trivia note: the original name for Monty Python’s Flying Circus was Owl Stretching Time - it was changed before the show went on air. But for that, I guess Python would have been called Owl or, possibly, Stretching...?). Ruby was apparently named just because its author. Matz, liked the sound of it (maybe with a sidelong reference to the Perl language too).
But I honestly have no idea where the Iron comes into the picture... (I think it reasonable to surmise that it may have been chosen by somebody with no knowledge of Cockney Rhyming Slang).
IronRuby was also the name of an independent .NET Ruby project which was the brainchild of Wilco Bauwer. This project has been rather slow in it development, however, and I have no real idea whether it is still alive.
I’ve explained previously how we latched upon the name, Steel, and British TV is once again to blame. I confess that I am still in the dark about the relevance of Iron. If anyone knows why IronPython and IronRuby are so called, I’d love to know...
Question: How will Ruby in Steel and IronRuby work together and coexist? I’m looking at the various options on the .Net platform with IronRuby and the QUT compiler.
I find it hard to believe that all the various options under .Net/VS will survive after a few years; I’m sure some of them will die off. I have no worries with Ruby in Steel surviving but in the mean time, will it interwork with all of these options easily?
To a large extent we are in the same position as you - that is, while we are pretty sure that Ruby will exist in some form under .NET, none of the current projects is sufficiently advanced to make a real predicition of the precise nature of Ruby in the CLR a couple of years from now. IronRuby is at a very early stage of development and naturally we shall follow its progress with interest ;-)
Our own clear goal is to offer the best support for the most important Ruby technologies when they emerge. Does that mean Ruby 1.9/2.0 and Yarv? Could it mean IronRuby, Rubinious, the Gardens Point compiler, JRuby or some other project? And what about Rails? Will that be challenged (maybe even overtaken?) by other frameworks?
At the present time, the two clear ’standards’ are Ruby 1.8x and the Rails framework. That’s why we are concentrating on offering the best possible support for Ruby.exe and Rails rather than for (say) JRuby and Nitro - but, over time, that could change. In fact, with a few tweaks, it’s pretty easy to develop in Ruby In Steel and target various VMs or compilers. I’ve already given some simple examples on this Blog showing how to target Ruby .NET and JRuby. In future releases of Steel, we’ll be adding tools and options to make it much simpler to switch between various interpreters/VMs/compilers so that you won’t have to jump through quite so many hoops in order to move from one to another.
We could pretty easily (I imagine) add this kind of ’choice of target’ support for IronRuby too. The real question to be answered is: but should be also provide tighter, dedicated support to take advantage of special features of IronRuby? Frankly, until the development of IronRuby itself progresses a bit more, we won’t be in a position to answer that question.
What is certain, though, is that if IronRuby emerges as a significant ’version’ of Ruby - one that our users need to use - then we’ll support it. But the same might equally apply to the other Ruby variants I mentioned earlier. If one of those emerges as truly significant to our users, we’ll support it.
What we won’t do, though, is make too many predictions at too early a stage. When I say we’ll support significant versions of Ruby (and Ruby frameworks) I mean that we will do so only when it is clear that there really is serious demand for that support. It would be disastrous for us to state here and now that we will offer integrated support for JRuby/Ruby .NET/Yarv/Rubinius/IronRuby at al. One or more of those may end up as an important platform. But, in my view, it’s far too early to bet our development efforts on which one(s) will be the winner(s).
As you might imagine, we we have given quite some thought to .NET support and we will aim to provide more details of concrete projects which we have under development later in the year.
Wilco stopped working on IronRuby a while ago. See his own post about this subject for further details! ;)
IronRuby is a nod to IronPython, the .NET version of Python created by Jim Hugunin. When IronPython was first started, it got a *ton* of negative feedback because ".NET can’t be used for dynamic languages." Jim kinda proved them wrong, and then got hired by Microsoft for his trouble. Microsoft is simply continuing it’s "branding" of interpretted/dynamic languages with this release.