The Ruby dynamic language, in particular the Ruby On Rails framework, has taken the Web development community by storm, owing to the ease of rapidly developing new Web applications. But thus far, the fruits of this effort have eluded .NET programmers in any finalized form. However, at least three efforts are now under way to make the Ruby environment more accessible to .NET programmers and the significant infrastructure that supports...
the .NET environment.
John Lam, a partner at ObjectSharp who is writing the RubyCLR bridge, explained, "For things like Web application development, frameworks like Rails are extremely useful because they reduce the amount of code people have to write, and more important, how much code you have to maintain. Those are things that consume the vast majority of time in software, because you usually don't get it right the first time. What makes Rails possible is an extremely dynamic language like Ruby."
With static languages like C#, the programmer is forced to make many decisions up front, so that when the inevitable change happens, there is more code to read, touch and understand. But this advantage comes with a tremendous performance hit. Lam said a tenfold decrease in performance is not uncommon. However, since Web applications tend to be more constrained by input/output limitations than processing time, this is not a significant problem. Lam noted, "I am not going so far as to say Web applications are the only domain, but when the server is sitting around for the vast majority of time doing nothing, there are a lot of tremendous opportunities for building code."
Queensland University of Technology Professor John Gough, who is leading the Ruby.NET implementation, said, "Ruby implementations are slow, even compared to other scripting languages. This is the price that is paid for the extremely dynamic semantics of the object type system, and the brute force approach to implementation by a tree-walking interpreter. The language has gained a popular following because of its expressivity, not its runtime performance.
"We see a role for scripting languages as glue that holds together computational frameworks that do serious background data crunching. The framework would typically be implemented in static languages while the scripting language provides a means for non-IT-specialists to manage their "eResearch" projects. If you accept this division of role, then clearly interoperation between languages is a primary requirement."
Of the three Ruby implementations for .NET, RubyCLR, which is a .NET bridge, has made the most progress, according to Lam, but it suffers from performance limitations because all of the code runs through a Ruby interpreter. The other two projects, IronRuby and Gardens Point Ruby (or Ruby.NET), are aiming to be native implementations on top of the .NET Common Language Runtime (CLR), which promise better performance in the long term, but will require more time to complete.
Lam said, "The advantage of the RubyCLR approach is that it works. I am further along than the other ones. They have to build a native language, which is a really challenging problem. I have the shortest path to get from A to B."
Lam has released three drops, which are roughly equivalent to Community Technical Previews. He doubts he will have the 1.0 version of RubyCLR out before the end of the year.
A beta version of the Ruby.NET compiler for Ruby was released in early August. It produces standard .NET program executable (PE) files either for immediate loading (in interactive mode) or for loading later. Thus libraries may be held as PE files rather than the usual Ruby source. The PE files only use the verifiable subset of the instruction set, so that 100% verifiability of object code is an attainable goal. This is important to ensure that Ruby code may be used as stored procedures in an SQL database, for example.
Gough said, "So far as I am aware, our implementation is the most complete, in terms of implementing most of the Ruby semantics, but is lagging in the area of interop, mainly because we have not addressed this aspect yet."
IronRuby is a Ruby interpreter for .NET, being developed by Wilco Bauwer in the Netherlands. Bauwer has released some previews of the interpreter, which he is hoping to be very similar to IronPython. Bauwer wrote on his blog that his goals are to first implement the Ruby language, including support for all of its semantics; then support at least the CLS (Common Language Specification); and finally implement both an (interactive) interpreter and a standalone compiler.