Ruby.NET future uncertain

The past two years have seen a lot of work in alternative Ruby implementations - next to the canonical MRI and its successor in Ruby 1.9, a host of other Ruby implementation project were started: JRuby and XRuby on the JVM, Ruby.NET and IronRuby for .NET and Rubinius, a selfhosting VM.
It seems that a certain consolidation is now happening: XRuby development has slowed down - because of JRuby's larger momentum and adoption, but also because of it's incompatibility with JRuby extensions that supply native Ruby functionality in Java (eg. OpenSSL, the Oniguruma regular expression engine, etc).

Dr. Wayne Kelly, who's behind Ruby.NET, now seems to have come to a personal decision in Ruby.NET vs. IronRuby, which he announced on the Ruby.NET mailing list:

Last week at the Lang.NET Symposium, I presented our work on the Ruby.NET project and also had the opportunity to learn more about the progress of the IronRuby project and the inner workings of the DLR (and also the JRuby project presented by Charles Nutter).
I've come to the conclusion that the DLR is clearly here to stay - it's becoming an even more important part of the Microsoft platform. I also believe that to obtain production quality performance, Ruby.NET would need to reinvent (or adopt) something equivalent to the DLR. If we were starting the project today, there is no way we wouldn't use the DLR. Whilst Ruby.NET initially had a good head start on the IronRuby project; by incorporating the Ruby.NET parser and scanner and by leveraging the DLR, I now believe that IronRuby is more likely to succeed as a production quality implementation of Ruby on the .NET platform. I believe that ultimately there is no need for two different implementations of Ruby on .NET. So, if Ruby.NET is ultimately not going to be that implementation, then we should not waste further developer effort fruitlessly chasing that goal.

The Dynamic Language Runtime (DLR) is a library that facilitates the creation of (dynamic) language runtimes. For instance, it shields developers from creating MS IL instructions directly - instead developers create DLR Trees, which the DLR turns into MS IL.

This approach has been getting some attention recently, as it removes a lot of work for the language implementer. Dermot Hogan, from the Ruby In Steel team, describes generating a DLR tree from an Antlr tree grammar:

Now the problem I've always had with Antlr is that having got the AST - what do you do next? Getting a simple grammar in Antlr is easy - but then you need a miracle to occur to actually do anything with it  emitting CLR code isn't simple. But connecting the Antlr AST to the DLR via the tree grammar is a trivial operation - see the code above. As is writing the DLR's "adapter" classes.

Some of the reactions to Dr. Kelly's message focus on the fact that IronRuby now seems to be the only viable Ruby on the .NET platform. For instance, Ola Bini, of the JRuby Team, says:

I don't like these news at all. In many ways having a strong competitor is something that will improve the ecosystem for everyone. Now IronRuby will become the only player on the field - unless other people (like Ted Neward and David Peterson) decide to pick up Ruby.NET. I hope someone does. The .NET world will be better of for it.
The crucial question is not whether we trust John Lam about IronRuby. The question is if we trust Microsoft to do the right thing. Do we?

This mentions an important point: since Ruby.NET is an Open Source project, the departure of one developer does not mean the project is shut down - developers can pick it up and continue development.

Meanwhile, John Lam, of the IronRuby team, has this to say:

We would like to extend a warm welcome to Wayne, and we invite anyone else who wants to work on IronRuby to join our Open Source project. Microsoft Research funded a portion of the development of Ruby.net, and their parser lives on in IronRuby thanks to the excellent work that Wayne did in producing the Gardens Point Parser Generator.
[..]
Having a single implementation on the CLR makes sense for the .NET community. Ruby isn't defined just by the language. It's defined by the programs that it runs. The hardest part of our project isn't getting the language right (although it certainly isn't easy) it's making sure that IronRuby runs Ruby programs. And regardless of what the Rails-haters say these days, Rails is an important program.

This is supported by a previous post, where John mentioned the current development strategy for IronRuby:

Finally, we talked about how we are going to get to 1.0. Right now we're going to switch to a goal-driven development process. Our next goal is to get 'gem install hoe' working. The Rakefile contains a task called 'gap', which lets you perform a gap analysis against a target application via the set_trace_proc interpreter hook.

This seems similar to Dr. Kelly's goal of supporting Rails:

I still feel we have unfinished business - we set our selves the goal of running Rails on .NET and we haven't achieved that yet. If we can leverage our experience to help IronRuby get to that point, then I'd at least have the personal satisfaction of helping see the job completed.

Note: No matter how important Rails is to .NET developers - it's a code base that exercises large parts of Ruby, particularly the metaprogramming features. Non-trivial Rails applications working correctly on IronRuby means that a large part of Ruby's features have been implemented correctly. Combined with the IronRuby project  running the executable Ruby specs defined by the Rubinius project, it should be possible to objectively determine how compatible IronRuby is.