Looking ahead to IronRuby

With the exception of the occasional Perl script, my development efforts are squarely within the .Net ecosystem. This is not really my choice.

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

In the .Net universe, it frustrates me 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 does not interest many developers. F# is a fun language for me to play in, but developers 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 reasons why I never tried working with Ruby, but many of them relate to the fact that I really like Visual Studio and the .Net Framework. All of that being said, it does not have anything to do with the Ruby language. RoR is not Ruby! It is a Web development framework and nothing more. I think that C# and VB.Net are great languages for gluing libraries up to a UI — I just do not like writing libraries in them, and they are not great for complex logic.

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

  • Have documentation.
  • Integrate with Visual Studio, including IntelliSense and debugging.
  • Work with the .Net Framework in a Ruby-like manner (and not like Java or C#).
  • Have a reputation for not being buggy or in perpetual beta or subject to a frequent release/revision/update cycle.
  • Receive as much support from Microsoft as VB.Net or C#.

Look at this list of "never was," "maybe will be," or "almost has been" Microsoft-backed .Net languages:

  • J# (I never figured out if this was supposed to be a Java clone or a JavaScript clone and no one else did either.)
  • Managed C++ (C++ is rapidly dwindling in favor of other languages for all but the most low-level or performance-sensitive applications.)
  • IronPython (It lacks Visual Studio support; its documentation is poor; and languages where indentation matters have never been popular.)
  • Perl.Net (It's 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# (It's still put out by Microsoft Research, but it's not viewed as ready for prime time as a result. It's a functional language, but it has poor documentation.)

I hope that Microsoft does IronRuby right. So far, it looks like it has 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 its full weight behind C#. If Microsoft treats IronRuby as a full partner in the ecosystem, it stands a good shot.


[Edited 8/22/2007 {Justin James} to add a link to "Chad"]


Justin James is the Lead Architect for Conigent.

Editor's Picks