IronRuby vs. Ruby.NET?
02. Jan, 2008 
3 Comments
In the spirit of Jon Udell’s Principle of Keystroke Conservation, I’m posting a follow-up to M. David Peterson’s write-up on the differences between Ruby.NET and IronRuby here.
David observes correctly that the key difference between the two implementations is IronRuby’s dependency on the DLR. The DLR provides some important benefits for 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.
There’s a few quotes that I would like to clarify:
“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)?”
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.
Here’s another:
“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.”
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.
[1] Bill Chiles on my team has been working hard on updating the hosting spec. I’ve got an updated version that I’ll post in a separate blog post.
There are two separate issues here. One is AOT compilation, and the other is CLS type construction. Confusingly, they are both[!] commonly called “static compilation”.
AOT compilation to IL is good for cold start time (which you mentioned) and some deployments (which you missed). I also would like to mention that ngen (and Mono’s equivalent) can be used to eliminate JIT time. I am eagerly waiting for return of this feature in IronPython. For comparison, JRuby 1.1 added this feature which was missing in 1.0.
CLS type construction is good for using (say) IronRuby code from C# without hosting interface as you said. But it’s also good for .NET attribute support (.NET attributes can only be attached to CLS type), and inheritance (C# needs CLS type to inherit IronRuby class). For comparison, JRuby doesn’t have this but Groovy does, and Groovy folks think it’s a very important advantage.
JRuby will also add a “static compiler” that allows integrating with Java’s type hierarchy in 2.0. I don’t expect it to be particularly hard to support…at least not nearly as difficult as writing the Ruby compiler in the first place.
Hey Now John,
Interesting Post.
Thx 4 the info,
Catto