A recent article by M. David Peterson on the O'Reilly Network entitled "Ruby.NET vs. IronRuby: What's the Difference" received the attention of John Lam, leader of the IronRuby project at Microsoft. John follows up David's article with some clarifications of his own with respect to IronRuby.
David's article is intended to point out the differences between Ruby.NET and IronRuby. David says about IronRuby:
* IronRuby is built on top of the Dynamic Language Runtime (DLR), an extension to the CLR geared towards providing support for the specific differences between statically typed languages (such as C#) and dynamically typed languages (such as Ruby).
And about Ruby.NET
* Ruby.NET is built on top of the CLR. Due to the fact that the DLR is an extension to the CLR (in other words, the DLR requires the CLR), there is nothing fundamentally different between what IronRuby is capable of and what Ruby.NET is capable of.
John explains the benefits of the DLR to the languages that target it:
- A shared code generation engine. It's a lot easier to use our code generation APIs than Reflection.Emit, so this saves time for compiler implementers. This also means that future performance improvements in the DLR show up for free in your favorite DLR-targeted programming language.
- A shared hosting interface. We act as a broker between the host and the programming language. You target the DLR, and our programming languages (and others that we don't create but target the DLR) come along with no extra effort on your part. My team is building hosts for both Silverlight and ASP.NET.
One question that comes to mind is why target the DLR at all if the CLR gives developers access to any CIL-compliant language. If this is the case the obvious choice is Ruby.NET over IronRuby.
David had originally questioned:
Do I want the increased interop between a broader base of languages provided by the CLR (and therefore go with Ruby.NET), or do I want the performance gained for dynamic languages by the DLR, (and therefore go with IronRuby)?
John responds explaining his own view:
I don't think that you lose anything in terms of interop with existing CLR-based languages by targeting the DLR. While it's certainly true that there's a lot that we can do to make dynamic dispatch better in existing CLR-based languages (would you rather call Office APIs from C# or VB.NET?) there's nothing today that prevents you from calling IronRuby library code from C#. As long as you do so via our hosting interfaces[1], things should just work. It's unclear to me how you can call arbitrary Ruby.Net code from C# without having to pass along all of the context goo that languages like Ruby require.
David also says:
The dynamically compiled nature of IronRuby fits well into the much less predictable world of client-side applications, where as the statically compiled nature of Ruby.NET fits well into the much more predictable world of server-side applications.
John's reply:
A key advantage of the static compilation model of Ruby.NET is minimizing cold start time. They still have CLR cold start to deal with since their assemblies must be JIT-ed whereas IronRuby needs to generate IL *and* JIT the code. So I would turn this argument around and say that for client apps where cold start time is crucial that this is an advantage for Ruby.NET. That said, we used to have an AOT compilation model for IronPython, and have since removed it from the feature list of DLR 1.0. This is something we would like to revisit in the version after 1.0.
David's original article was modified after John Lam posted his comments but the article leaves some unanswered questions. One aspect of Ruby.NET and IronRuby which current Ruby developers want to know, is when Ruby on Rails will run on either platform. One developer from the Ruby.NET camp indicated there were several key components of the Ruby implementation that needs to be developed before entertaining the idea of running Ruby on Rails on Ruby.NET. There has not been any concrete information if and when IronRuby would run Ruby on Rails but John Lam indicated at RubyConf this year.
Seo Sanghyeon indicated the easiest effort to get Ruby and .NET integration now would be with RubyCLR, which is a project created by John Lam.
There is certainly many issues to consider when looking at choosing IronRuby, Ruby.NET or RubyCLR and these projects are in their infancy, so keep a close eye on each of them if writing Ruby code on the .NET platform is to your liking.
Additional information about IronRuby can be found at the IronRuby web site and keep track of John Lam at his blog.
