Ruby.NET future uncertain

Posted by Werner Schuster on Feb 05, 2008

Sections

Architecture & Design,

Development,

Operations & Infrastructure

Topics

Open Source ,

Ruby on Rails ,

Ruby ,

.NET ,

Dynamic Languages

Tags

DLR ,

Rails ,

IronRuby ,

RubyDotNet

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.

1. Back to top

   Rubinius.NET

   by Aslak Hellesøy

   Kudos to Dr. Wayne Kelly for taking the high road here. His work has been highly influential, both culturally and technically and I hope he'll continue to contribute to Ruby on .NET in one way or another.
   
   Now I'd love to see Rubinius running on .NET/DLR (as well as on Java) so we get some more competition here.

   Reply

2. Back to top

   More Choices or Better Choices

   by 茅 盛

   The community will be better served, if Ruby.NET would continue to be a alternative. But if all of them merge, resources (for open source communities, they are always insufficient) would get better used. What to choose?

   Reply

3. Back to top

   Wise step by Dr. Wayne Kelly

   by Soft Mind

   Hi,
   
   I think its a really wise step taken by Dr. Kelly. He thinks positive in terms of growth of Ruby.Net Community and better results to be achieved through DLR.
   
   In this fast moving world, it makes no sense reinventing the wheel again and again.
   
   I find surprised when developers think that IronRuby is now the only solution for .Net. What's the big issue about that. One is enough, if its great enough to cater all needs. Even Jruby is now a standalone, since Xruby will never take off as expected.
   
   I judge the Software with the quality, rather than quantity available.
   
   Just my 2 cents.
   
   SoftMind

   Reply

4. Back to top

   Re: More Choices or Better Choices

   by Jonathan Allen

   I am firmly in the "better choices" camp. Ruby.NET set out to prove that it could be done, which it did, and now it is time for it to step aside and let the next language take its place.
   
   Too often experimental languages linger on longer than they should, sapping the resources of their creators and the languages that should have replaced them.

   Reply

5. Back to top

   Re: More Choices or Better Choices

   by Werner Schuster

   Next language? What "next" language? The effort going into Ruby.NET is now directed at completing IronRuby.

   Reply

• Older >