Channel Register

Original URL: http://www.channelregister.co.uk/2008/03/17/ironruby_work_schedule/

No Borg-like release train for Ruby on .NET

By Tim Anderson
Published Monday 17th March 2008 06:02 GMT

Microsoft hopes to deliver the .NET-tuned implementation of the phenomenally popular Ruby, IronRuby (http://www.ironruby.net/) 1.0, by the end of this year.

There's a ton of work left between then and now, though, and project manager John Lam isn't falling for that old Redmond trick of committing to a date and then watching the software slide out of view. Some stuff is getting cut, though.

Lam told Reg Dev he hopes to have an early implementation of Rails in time for RailsConf in Portland, Oregon at the end of May.

The date sounds ambitious and is not firm, though. "We're not driven by some Microsoft-ian ship train thing," Lam said, adding that determining what "done" means is a challenge. IronRuby was announced almost a year ago, in May 2007.

"The language is still changing, there is no spec for the language, there are going to be differences between implementations that are essentially undefined behavior." His approach is pragmatic. "How we declare [version] 1.0 is: are there any serious blocking bugs preventing people from getting things to work?"

So, what's left to be done? "We don't run real Ruby applications today," he said. "On the language side we're still missing two or three features. The biggest one is being able to eval [sic] strings of code. It's probably another month's work."

Then there are the bugs. "The big thing that blocks us from running real Ruby programs is the libraries," Lam said. His team is tracing API calls made by libraries under the C version of Ruby, in order to see what still needs implementing.

"The first milestone is to get RubyGems working, which is the packaging system in Ruby. After that we want to get Irb working, the console interactive mode inside of Ruby. Finally we've got all the traces done for Rails as well."

Some familiar features will not be implemented, however. "Call with current continuation, we're not implementing that. [Although] JRuby (http://jruby.codehaus.org/) isn't either. Another example is ObjectSpace, this feature in Ruby where you can walk the managed heap of all live objects at runtime. It's very expensive for us to implement that feature. What we will likely do is by default, not track all the objects on the heap. If you want to use this feature, you've got to run it with a switch."

Which begs the question: why bother with Ruby on .NET at all? "There's a lot of rich libraries inside of .NET," said Lam. "There's stuff that talks to the OS and Silverlight. It's important to see Ruby running in the browser. None of the other Ruby implementations are security hardened to the point where they could just plop into Firefox or IE. We've also got companies that want IronRuby on Rails. They're willing to pony up devs to help us finish."

The last point is interesting. IronRuby is open source - anyone can help. According to Lam, it is a new Microsoft - though note, this is the developer division we're talking about, not the Windows or Office cash cows.

Finally, why should .NET developers bother with Ruby? According to Lam: "You spend less time writing software than you spend maintaining software. Optimizing for writing software versus maintaining software is probably the wrong thing to do. Static typing makes it harder to maintain software because it's harder to change it."®

© Copyright 2008