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.
