A brief history of Ruby on .NET

John Lam recently responded to a post by M. David Peterson about the differences between Ruby.NET and IronRuby. A few months ago Dr. Nic (inadvertently) made it seem like the two projects are at odds. Afterwards the Softies on Rails guys seemed to question Microsoft’s interest in Ruby and were disappointed with Microsoft’s “lack of support” for Ruby.NET. There seems to be some confusion about the relationship between IronRuby and Ruby.NET. Implicit in some online conversations about IronRuby and Ruby.NET is a distrust of Microsoft doing the right thing in regards to Ruby. I’ve read many statements that imply Microsoft is trying to kill Ruby.NET. I’ve also read that Microsoft is trying to kill Ruby! So for all those that haven’t been following Ruby’s adventures on Microsoft’s .NET framework, here is a (very) brief history as I remember it. Corrections are welcome.

NETRuby

Actually, Ruby.NET wasn’t the first Ruby implementation on .NET. Sure, there were Ruby to .NET bridges like John Lam’s RubyCLR and SaltyPickle’s Ruby/.NET Bridge before, but there was also an actual port of Ruby 1.6 to .NET by arton. This project was called named NETRuby and it was a straight port of the Ruby C code to C# in 2001. I think I got it working on some small things, and I found the code pretty interesting. But the effort eventually died from lack of attention and/or need, as it was started and abandoned long before Rails was born and brought so much attention to the Ruby language.

The First IronRuby

Another early Ruby on .NET project was Wilco Bauwer’s IronRuby project. Wilco based his implementation on the IronPython implementation. Although the current IronRuby project shares the name, the two projects don’t share any code. I don’t believe Wilco ever publicly released the source code for his implementation. I do remember playing with the compiled version he released, but it was far from complete.

Ruby.NET

Around the time that Wilco was talking about his IronRuby implementation, the Queensland University of Technology folks announced that they had received funding from Microsoft Research to implement Ruby on the .NET Framework. I remember that Microsoft was just starting to show more interest in dynamic languages, due to the success of IronPython and the sudden and overwhelming emergence of Ruby (largely because of Rails). Ruby.NET’s runtime involves creating wrapper objects for the .NET objects to implement all the Ruby-ish features. This is a very common approach for implementing dynamic languages on a static language runtime. The early work from the Queensland guys resulted in code drops every six months or so. As the project has matured the releases became more frequent until the code was eventually put into a public subversion repository on Google’s service.

The Current IronRuby

Microsoft’s investment in Ruby.NET was rewarded when John Lam joined Microsoft to implement Ruby on the yet to be announced Dynamic Language Runtime (DLR). The DLR sits on top of the CLR and allows IronRuby to add Ruby-ish features to the .NET objects without creating proxies. The DLR also allows different dynamic languages to interoperate in the same way that languages such as C# and VB.NET can interoperate on the CLR. For legal reasons John’s team can’t look at the original C implementation of Ruby (you can listen to my Rubiverse podcast interview with John for the details to why this is), but was able to license and look at the Queensland implementation of Ruby.NET. John’s team was also able to use parts of Ruby.NET to more quickly stand up IronRuby. Although it seems that the parts of Ruby.NET in IronRuby are scheduled to be replaced in order to provide better future integration with the Visual Studio IDE. So that’s is. The efforts are dramatically different in their implementation, and address different needs. I see them both as complementary, and having a similar relationship as the one between JRuby and XRuby.