Looking ahead to IronRuby

Many of us are forced (for good or ill) to code within the .NET ecosystem. With the impending release of IronRuby, .NET developers will finally be able to try this interpreted, flexible and object oriented language without giving up Visual Studio or the advantages of the .NET framework.

With the exception of the occasional Perl script, my development efforts are squarely within the .Net ecosystem. My choice? Not particularly. I like the .Net Framework because it encapsulates 90% of the dull plumbing work. I like the .Net CLR because it lets me use the best language for the job (in theory, when an alternative exists and works well). But I find VB.Net fairly unpleasant for many tasks, and C# does not particularly thrill me either, although C# 3.0 is changing my mind a bit. One of the things that does frustrate me a bit in the .Net universe, is that anything outside of VB.Net or C# is viewed as a "risk" simply because it is not a full blown Microsoft product, and all too often does not "feel" like a mainstream language. Many of these fears are fairly well founded. IronPython lacked Visual Studio support when I tried it (after its official release), and Python is not a language that many folks have interest in. F# is a fun language for me to play in, but folks who enjoy working with a functional language are rare, and those who use them well are rarer still.

Enter IronRuby (thanks for the link Chad).

The Ruby language has interested me for some time now. From what I can tell, it combines much of the flexibility that I appreciate in Perl, a solid object model, and is a dynamic/interpreted language to boot (I have a soft spot for them). I can come up with a dozen or so reason why I never actually tried working with Ruby, but many of them relate to the fact that I really like Visual Studio and that I really like the .Net Framework itself. All of that being said, it does not have anything to do with the Ruby language itself. RoR is not Ruby! It is a Web development framework, and nothing more. And to be honest, I think that C# and VB.Net are great language for gluing libraries up to a UI. I just do not like writing libraries in them, they are not too great for complex logic.

So when IronRuby hits, I will definitely be willing to give it a shot. I know that for it to gain any kind of widespread adoption, it needs to meet the following criteria:

|> Documentation
|> Visual Studio integration, including IntelliSense and debugging
|> Work with the .Net Framework in a Ruby-like manner, not a Java-like or C#-like manner
|> Be viewed as not being in perpetual beta, buggy, or subject to a frequent release/revision/update cycle
|> Be as supported as VB.Net or C# by Microsoft

Without those, it is sunk. Look at the list of "never was", "maybe will be", or "almost has-been" Microsoft-backed .Net languages:

|> J# (I never figured out of this was supposed to be a Java clone or a JavaScript clone, and no one else did either)
|> Managed C++ (C++ is rapidly dwindling is favor of other languages, for all but the most low-level or performance sensitive applications)
|> IronPython (lack of Visual Studio support, languages where indentation matters have never been popular, poor documentation)
|> Perl.Net (not really Microsoft, but ActiveState has close ties to Microsoft, it lacked Visual Studio support and was very odd to work in, particularly due to Perl's object model clashing with the .Net Framework)
|> F# (still put out by Microsoft Research, not viewed as ready for prime time as a result, functional language, poor documentation)

So here's to hoping that Microsoft does IronRuby right. So far, it looks like they have a smart, dedicated team of folks working on it, but that is not enough. The difference between C# and J# or F# or IronPython is that Microsoft put their full weight behind C#. If Microsoft treats IronRuby as a full partner in the ecosystem, it stands a good shot.