Microsoft's announcement of IronRuby, a Ruby implementation that runs on .NET has caused a lot of debates in the Ruby space. Ola Bini, JRuby team member, kicks of another one by expressing doubt about the feasibility of the project. He bases this opinion on one crucial problem behind IronRuby: the developers supposedly cannot look at Ruby's source code due to copyright or license issues. Another problem is Microsoft's refusal to accept outside code contributions. Ola explains:
Another flaw in this logic is the view that every developer using Rails on .NET must have switched over from ASP.NET, thus incurring a profit loss for Microsoft. But this is not necessarily the case. Switching an experienced ASP.NET team to using a different language and framework incurs retraining costs. The advantages from switching to Rails must be considerable for a particular project for that to happen. There is also the question, whether all .NET developers would see the benefit of this, when they can chose from a host of technologies from Microsoft. Aaron Erickson, a .NET developer, explains his perception of the the Microsoft platform at the moment:
The group of developers that would drop their tools and switch to Rails are the same that did this on the Java platform, the people who ditched Struts, JSF and Co to work with Rails. This is a group that is either dissatisfied with the old ways of solving problems or developers new in the web space who aren't used to the old ways yet.
The availability of a full Rails version on .NET would ensure that developers interested in Rails could stay on the .NET/Microsoft software stack, and retain most of their experience (with Windows, IIS, Visual Studio, etc). If Rails is not available, then there's a chance that this group will wander off to use a Non-Microsoft stack for Ruby, maybe switch to JRuby on Rails on another Operating System and Web server. With a full Rails implementation, Microsoft can keep developers on the .NET/Microsoft software stack, and with good tool support, it could attract new ones. This results in a direct benefit for Microsoft: companies using Windows and Microsoft server software and tools will pay license fees for this software, not to mention support contracts or training courses. As for IDE support, Ruby in Steel already offers state-of-the-art support for Ruby and Rails in Visual Studio.
The general idea: making .NET more attractive for a wider audience can retain and maybe attract paying customers, without cannibalizing sales of other products.
Unconvinced about IronRuby's chances, Charles mentions another way to bring Ruby to the .NET platform:
Debates like this make the first release of IronRuby ever more interesting. John Lam, IronRuby's developer, recently mentioned the first public release of IronRuby will happen at O'Reilly's OSCON, July 23-27, 2007.
I am going to make a bold statement here. Under the current circumstances, I don't believe it's possible for John Lam and his team to create a Ruby implementation that runs Rails within at least 18 months. And frankly, that's not soon enough. As I said above, I have all confidence that John can do great stuff if he has the right resources. But creating a Ruby implementation is hard enough while having all the benefits of the open source community.Ola's solution is to focus on speeding up the work on a full Ruby specification:
The two points I want to make with this point is this: The Ruby community must damned well get serious about creating a good, complete specification and test suite. It's time to do it right now, and we need it. It's not a one-man job. The community needs to do it. (And yes, the two SoC projects are a very good start. But you still need to be able to run RSpec to take full advantage of them; and let's face it, the RSpec implementation uses many nice Ruby tricks.)The specification effort is already going on:
- Google SoC sponsors two students to work on RSpec tests for the specification (InfoQ recently featured an interview with one of the students )
- JRuby's Charles O. Nutter has long ago started a Wiki for the Ruby specification
- The Rubinius project has also been busy creating many RSpec tests to check compatibility and they cooperate with the JRuby team on this too .
Having run the Ruby gauntlet and brought JRuby from not running anything to running Rails almost 100% perfectly (in just over a year, I might add), I will confidently say there's no way with current specs and tests that anyone could create an implementation of Ruby from scratch that will run Rails unless they can look at the existing implementations. I simply do not believe it's possible.Charles also suspects a lack of determination on Microsoft's part:
This is a good friend's belief, but he's won me over: we don't believe Microsoft would ever willingly allow IronRuby to get to the point of running Rails, since that would directly compete with their ASP.NET server, software, and tool offerings. What would be the benefit to them of a free runtime running a free language implementation that runs a free web framework? Probably zero.This is a surprising statement (to say the least) coming from a developer employed by Sun to work on JRuby. Sun employs two full time developers to work on JRuby and two more to work on the Netbeans Ruby tools. Yet, Sun won't see a single dime in return of this investment directly, since JRuby is an independent project (it's not a Sun project) and the Netbeans tools are free of charge. Actually, using Charles' reasoning, Sun would not want a JRuby capable of running Rails, because developers using JRuby on Rails won't use JSP, JSF or any other Java technologies. So, unless developers or companies use JRuby on Rails on Sun hardware or use Sun's software support services for running on Sun software, Sun doesn't earn any money from this effort. So, by Charles' logic, there shouldn't be four Ruby runtime and tool developers on the payroll. Yet there are.
Another flaw in this logic is the view that every developer using Rails on .NET must have switched over from ASP.NET, thus incurring a profit loss for Microsoft. But this is not necessarily the case. Switching an experienced ASP.NET team to using a different language and framework incurs retraining costs. The advantages from switching to Rails must be considerable for a particular project for that to happen. There is also the question, whether all .NET developers would see the benefit of this, when they can chose from a host of technologies from Microsoft. Aaron Erickson, a .NET developer, explains his perception of the the Microsoft platform at the moment:
Having spent the better part of 14 years doing Microsoft based development, there has never been a time where I was more proud to call myself a Microsoft platform developer. The stuff coming from Anders Hejlsberg and the C# team, let alone the stuff coming out with the DLR and Silverlight, is some of the best innovation this business has seen in years.If more .NET developers think like this and are fully satisfied with the technologies and tooling that Microsoft provides, then there is not much chance of mass migrations from .NET tools to Ruby.
The group of developers that would drop their tools and switch to Rails are the same that did this on the Java platform, the people who ditched Struts, JSF and Co to work with Rails. This is a group that is either dissatisfied with the old ways of solving problems or developers new in the web space who aren't used to the old ways yet.
The availability of a full Rails version on .NET would ensure that developers interested in Rails could stay on the .NET/Microsoft software stack, and retain most of their experience (with Windows, IIS, Visual Studio, etc). If Rails is not available, then there's a chance that this group will wander off to use a Non-Microsoft stack for Ruby, maybe switch to JRuby on Rails on another Operating System and Web server. With a full Rails implementation, Microsoft can keep developers on the .NET/Microsoft software stack, and with good tool support, it could attract new ones. This results in a direct benefit for Microsoft: companies using Windows and Microsoft server software and tools will pay license fees for this software, not to mention support contracts or training courses. As for IDE support, Ruby in Steel already offers state-of-the-art support for Ruby and Rails in Visual Studio.
The general idea: making .NET more attractive for a wider audience can retain and maybe attract paying customers, without cannibalizing sales of other products.
Unconvinced about IronRuby's chances, Charles mentions another way to bring Ruby to the .NET platform:
Given these facts and the current situation, I'd say it's a better bet for us as a community to get behind the Gardens Point Ruby.NET Compiler project, which is already much farther along than IronRuby...plus it's real open source (you can contribute) and they can look at Ruby's source (and have admitted to doing so for at least the parser). I was wary/skeptical of Ruby.NET last year, but they now seem like the current best hope for Ruby on the CLR.The Gardens Point Ruby.NET compiler project is an active project to create a Ruby to .NET bytecode compiler. It ships with an executable that behaves just as the ruby or jruby command line versions, but instead of interpreting Ruby Abstract Syntax Trees (ASTs), this will compile Ruby code to MSIL (the instructions set used on the CLR) before it runs.
Debates like this make the first release of IronRuby ever more interesting. John Lam, IronRuby's developer, recently mentioned the first public release of IronRuby will happen at O'Reilly's OSCON, July 23-27, 2007.
