Give Ruby.NET 0.9 some love

A few days ago Microsoft announced the final release of Visual Studio 2008 and .NET 3.5. As expected, .NET developers were impatiently awaiting such a major release, which introduces countless improvements and new features within the IDE, the framework and the compilers for the two main languages, C# 3.0 and Visual Basic 9. It didn’t take long for the news to spread across the blogosphere, with all sorts of details for those interested in the Microsoft platform.

What didn’t get much attention, as far as I can see, is the almost concurrent release of the first community edition of Ruby.NET (version 0.9). For us Ruby lovers, this is a significant event which deserves to be the focus of this post.

Back in July of this year, Queensland University of Technology (QUT) decided to entirely transfer the control and ownership of the project — that was initially sponsored by Microsoft Research — to the Ruby and .NET open source communities. The project was formerly known as Gardens Point Ruby.NET and the first beta of the compiler was made available back in June of 2006 by the leaders of the project, Dr. Wayne Kelly and Prof. John Gough. Renaming the compiler was a choice that aimed to reflect the desire to make the project truly independent and open source; code from the community for the community. It is however reassuring to know that QUT’s staff (who has a solid track record of delivering compilers) continues to be heavily involved with the project and their commitment, along with the work of the community, has permitted the launch of this community edition release in the span of just a few months.

Ruby.NET 0.9 includes substantial improvements, and amongst the many bug fixes, it is worth mentioning the improved Ruby and .NET interoperability, the possibility to visually design Windows Forms application within Visual Studio, the creation of .NET delegates through Ruby blocks, and .NET sub-typing.

Ruby.NET should not be confused with IronRuby, the alternative project I mentioned in a couple of posts, a few months ago. There are several differences between the two projects, but I feel that the two strongest distinguishing factors at this stage are the maturity and, I suspect, the affiliation of the projects. IronRuby is hosted at RubyForge but it’s still in pre-alpha mode, but no files have been released to date on RubyForge (albeit you can grab the code directly from its repository). Ruby.NET on the other hand, is at version 0.9 and is almost production ready. The final test — being able to run Rails — has not been passed yet, but it is clear that the project is getting closer and closer to a production quality 1.0 release. Furthermore, Dr. Kelly is open to work together (w.kellyATqut.edu.au) with those who intend to use the compiler for production purposes, as a form of showcasing examples of real world usage.

From an affiliation and legal standpoint then, IronRuby as a Microsoft project, is released under the Microsoft Permissive License, while Ruby.NET can be considered fully open source and independent from any vendors at this stage (and it has a BSD license). Depending on how you see this, it can either be an advantage or a drawback.

When discussing languages such as Java and C#, it’s rarely the JVM or the CLR (Common Language Runtime) which is the subject of harsh criticism, but it’s rather the language itself, for its verbosity, complex design patterns required to solve simple tasks, or its lack of advanced features, in the eyes of the experienced programmer who has experimented with Ruby, Python, Lisp, Haskell, Erlang and similar languages. In response to these needs, the industry has reacted with a couple of trends. The first approach is that of using a common virtual machine and also offering a handful of advanced but less common languages for it. Ruby.NET, IronRuby, IronPython, JRuby and Jython are all examples of this. At least in theory, this offers developers the possibility to program in their favorite language while still integrating their code with the existing one, and relying on “enterprisey” runtimes, frameworks and libraries that are accepted also by the least adventurous IT managers.

The second trend, adopted by both Microsoft and Sun is that of improving upon the main promoted languages, C# and Java respectively, by integrating functionalities and programming paradigmas taken from functional, distributed and research languages. The two approaches are somewhat complimentary but they end up meeting asymptotically when advanced, research, “toy” and less common languages become more “real” and are fully integrated on the Java and .NET platforms, and mainstream languages like C# become advanced and sophisticated enough to please the most refined developers.

This convergence is harder in practice, especially if we get into the topic of side effects and purely functional languages. But for mixed paradigm languages like Ruby, the advantages deriving from projects like Ruby.NET or JRuby are clear. As a Technical Evangelist, for example, I interact with many consultants and their most frequent question is always about suggestions on how to introduce Ruby into environments that are typically against anything new and “not yet proven”, especially if open source. For shops that heavily rely on Java or .NET, a production ready JRuby or Ruby.NET is a free ticket to the introduction of Ruby within the company, without requiring too many changes, risks or raising any alarms in conservative settings. In the case of Ruby.NET, it works with Mono too, so it doesn’t have to be limited to Windows either.

Let’s give some love to this important project, as it may help us to soon write Rails applications which seamlessly interact with ASP.NET, or visually design nice desktop ones whose program logic is powered by Ruby (and we all know what a boost in productivity that can be).

I invite you to blog about the release of Ruby.NET 0.9 and if you know at least a bit of Ruby or C#, to contribute to this very promising project. You can start by reading the page for the contributors and the PDF paper Ruby.NET: A Ruby Compiler for the Common Language Infrastructure for an architectural overview of the implementation.