UPDATE: John Lam has followed-up with a response on his blog. For what I assume are obvious reasons I would pay attention to what John has to say on the matter well before anything I might have to say as, again quite obviously, John kind of knows a thing or two hundred about these kinds of things. ;-)

To ensure I’m not propagating bad information I’ve integrated portions of his comments that help clarify the real picture as it is (as opposed to how I may have interpreted things to be) into the body of this post. That said, if you haven’t already I would encourage you to head on over to his post *first* and then come back here if/when time allows.

Thanks for the follow-up, John!

[Original Post]
Pat Eyler asked me a while back for my thoughts on a handful of questions related to both IronRuby and Ruby.NET. He recently posted my answers to the following questions,

* How much are the IronRuby and Ruby.NET projects working together?

* Where/how could they better cooperate?

* What’s the easiest way to get started with Ruby.NET for Windows, Mac, and Linux users?

* What are some ways the Ruby.NET team is working with the larger Ruby community?

* What more could they be doing?

* Why should we trust Microsoft?

Extending from these answers and in response to a follow-up question from Pat, it seemed appropriate to pull together a summary of the core differences between the Ruby.NET and IronRuby projects. This summary extends from the thread @ http://groups.google.com/group/RubyDOTNET/browse_thread/thread/a8c51748456a46c0/0e6ad247c1e059e9?lnk=gst&q=Ruby.NET+and+IronRuby with plenty of extended substance from Douglas Stockwell, Charles Oliver Nutter, and Dr. Wayne Kelly that is worthy of your click.

PLEASE NOTE: If anyone from either the Ruby.NET or IronRuby camps (I claim myself a member of both) feels compelled to clarify or provide either an extended and/or counter follow-up, by all means please do. If it turns out that any of what follows is either inaccurate, misleading, or in other forms doesn’t present the complete story, please let me know and if seems justified, I will incorporate the suggested changes into the body of this post.

Thanks in advance!

Ruby.NET vs. IronRuby: What’s The Difference?

Common Language Runtime and the Dynamic Language Runtime

* 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).

* 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.

Of course one can theoretically do a lot of things with XSLT that you can do with any other language. But that doesn’t mean it’s a good idea, just that it’s possible.[1] In this regard, understanding the benefits and disadvantages of targeting the CLR or DLR will be helpful in making the determination as to which tool is the right tool for the job at hand.

Benefits of building a Ruby compiler/runtime on the DLR

The primary benefit of the DLR beyond being tuned to the specific needs of dynamic languages is that of cross language compatibility between other languages built on the DLR. In other words, true to the spirit of the Common Language Runtime, a library built for IronPython 2.0 will be accessible to your IronRuby code base as well as Dynamic VB(VBx) and the new DLR JavaScript compiler, and therefore JavaScript(3.0) itself.

Benefits of building a Ruby compiler/runtime on the CLR

Conversely, a library compiled by Ruby.NET is accessible to any CIL-compliant language, which neither IronPython, IronRuby, or any other DLR-based language will have the ability to do.

[UPDATE]: I should have made greater emphasis on the nature of a Ruby.NET assembly: Just like any other CLR language compiler that generates verifiable PE files, a Ruby.NET compiled assembly is just that: A pre-compiled .NET assembly that can be referenced inside of another .NET project in the same manner that an assembly compiled by a C# compiler can be referenced. I tend to use the term “static compilation”, but as Seo contends,

I think AOT(ahead-of-time) is better terminology than static, since compiled Ruby.NET code is not statically dispatched. It’s just dynamic dispatch compiled ahead of time.

… maybe using the term static compilation should be eradicated from my Ruby.NET vocab and replaced with AOT compiled assemblies? Seems like a good idea, so that’s what I plan to do.
[/UPDATE]

With the above in mind, the question might be asked: “Why target the DLR at all if I can target the CLR and gain the advantage of providing access to any CIL-compliant language, not just those languages targeted at the DLR”, which is a fair question.

To me, anyway, the answer really boils down to the advantages and disadvantages of using a statically-typed language compared to a dynamically-typed language.[2] Ultimately what it will all come down to is whether or not Microsoft is able to build into the DLR features and functionality that provide clear performance advantages for dynamic languages that can not be obtained by targeting the CLR on its own. If they are able to deliver (and I have every reason in the world to believe that they will), then it’s not going to be a question of “Why use IronRuby over Ruby.NET?” and instead “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)?”

JL: 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.

If I were to make a prediction as to where you will most likely find Ruby.NET being used compared to where you will most likely find IronRuby being used it would be on the server (via, for example, an ASP.NET application) and the client, respectively, though by client I am referring more so to the browser than I am your typical desktop application. That’s not to suggest you won’t find IronRuby on the server, nor Ruby.NET on the client, and instead that 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.

JL: 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.

Integration w/ Silverlight

* While at present time this is not the case, at some point in the future (middle of 2008?), IronRuby will be available for use in applications targeted towards Silverlight, which for all intents and purposes means support for the Ruby language in IE, Mozilla++, Safari, and Opera on Windows, GNU/Linux/Unix, and Mac OSX (Intel-only, though it’s possible that PPC support could come via the Moonlight project).

* While it’s possible that Ruby.NET could be modified to run on Silverlight, given IronRuby is being built on top of the DLR, and given that the DLR will be an integral part of the Silverlight distribution, it’s not completely clear what the advantages would be.

Shared Code Between Projects

This is a question I believe deserves quite a bit of attention from both the IronRuby and Ruby.NET camps: If I write code for Ruby.NET (while this is fairly obvious, it’s important to point out that the first time someone adds something similar to “require ‘mscorlib.dll’” to their otherwise pristine Ruby code base, this code base is no longer portable across Ruby implementations…
[UPDATE: As Seo points out in a follow-up conversation: “this only applies if you don’t rescue LoadError or detect platforms and write implementations for each. Let’s say “…”require ‘mscorlib.dll’” to their otherwise pristine Ruby code base *without fallback*“. ) ]
… will I be able to use this same code inside of IronRuby, and vice-versa. Until both projects reach a 1.0 status, I doubt much a solid answer can be provided, but I do believe this should certainly be a goal for post 1.0 releases of both projects.

Support for the Core Ruby Language and Libraries

* Ruby.NET has been tested (and passed) against the Ruby 1.8.2 core ruby libraries, and as of the latest release (0.9) provides near-to-complete support of the Ruby language.

* At this point in time (the first IronRuby alpha was made available on July 23rd, 2008 2007 [NOTE: Thanks for the catch, Joshua!], the first day of OSCON, and while many updates have been made to the code in the repository, no new official releases have been made since) IronRuby has limited support for both the language and the core Ruby libraries.

Update

What about support for Ruby on Rails?

From what I understand, John Lam suggested at RubyConf that providing support for RoR via IronRuby was definitely something they are aiming to achieve. Can someone clarify one way or the other?

From the Ruby.NET side there are only a handful of obstacles left to overcome, the most significant of which is how to handle libraries that have the same name, but different directory hierarchy. For example, net/http and uri/http. The related threads can found at [thread one | thread two] and the related bugs @ [bug one | bug two]

CORRECTION: Seo Sanghyeon recently followed up a post I made to the Ruby.NET and IronRuby dev lists with the following clarification regarding support for RoR via Ruby.NET,

This is not my impression. For example, there needs to be an implementation of Socket. And Mutex. And another “same name” issue, i.e. thread.rb and thread.so. And who know[s] what.

Not to mention ADO.NET backend to ActiveRecord (like ActiveRecord-JDBC) and other niceties. By the way, I think a lot of Ruby and .NET integration can be developed right now, without waiting for IronRuby or Ruby.NET, by using RubyCLR which has no compatibility problems.

It would be interesting to hear John Lam’s take on the above given the fact that he is the creator of the RubyCLR project and now, as we all know, heads up the IronRuby project.

Actually, for that matter it would be really interesting if somebody in the know could provide greater insight into why one might choose RubyCLR over Ruby.NET and/or IronRuby and vice-versa. Anyone care to tackle this subject?

—
[1] see: http://dev.aol.com/blog/mdavidpeterson/2007/03/14/fizz-buzz-in-xslt-1.0 as a good example, a post that was written to highlight my belief that the “FizzBuzz” problem was being approached from the wrong perspective, not from the standpoint that XSLT 1.0 was the most clear, concise, and proper language to solve the problem with. That said, the XSLT community certainly jumped in and did their part to highlight how XSLT 2.0 provided a way to have your cake and eat it too > http://dev.aol.com/blog/mdavidpeterson/2007/03/14/fizz-buzz-in-xslt-2.0 < but as is usually the case, I digress... ;-)

[2] For those interested in gaining greater insight, please see http://dev.aol.com/blog/mdavidpeterson/2007/02/20/ror-and-the-dotnet-platform_let-go-to-embrace which goes into a bit more depth as it relates to the advantages and disadvantages of static versus dynamic languages, a topic which is bound to be a *VERY* hot topic of debate over the coming months and years.