Ruby.NET is dead! Long live Ruby.NET?

I’m not really a Windows or .Net kind of guy, but I’ve tried to keep an eye on the Ruby.Net and IronRuby. While neither has been as visible inside the Ruby community as, say, Rubinius or JRuby, Ruby.NET has always had a harder time ‘getting the word out’.

Yesterday, Dr. Wayne Kelly wrote an email that said in part:

[W]e set our selves(sic) 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.

These are just my views. As a researcher, my prime interest is not in developing products, but in developing innovative new ideas and having an impact by having those ideas used in the real world. I’m aware that others in the community will have different goals and so will presumably have a different take on this – I’m keen to hear what you think. If anyone wants to press ahead, then the code base is still owned and controlled by you the community, so you are free to do with it as you please with our full blessing.

I’d also like to make it very clear that this decision is entirely my own – based on research and technical considerations. Microsoft did not in any way suggest or encourage us to kill the project and we thank them again for their support of the project.

I’d like to thank all of our contributors and supporters and apologize if this decision comes as a disappointment. I hope many of you will join me in contributing to the IronRuby project and see it through to a successful completion.

There were two quick responses from the community, from M. David Peterson and Ted Neward which read as though they (at least) will be continuing to work on Ruby.NET. Peterson wrote:

No, in all seriousness after my recent “Ruby.NET Is NOT Dead” speech Dr. Kelly contacted me directly to let me know he was considering what follows. And after reading his thoughts and discussing things with him further I absolutely 100% both stand behind and believe this is the right decision for HIM to make.

Neward responded:

He sent same to me, and while I’m completely behind the idea of HIM moving on if he feels the need/desire to, I still believe that there is room in the world for both a statically-compiled Ruby and a dynamically-interpreted Ruby on the CLR.

Assuming Peterson and Neward move forward with this, and I hope they do, they need to ensure the Ruby.NET community is working harder to engage the broader Ruby community. There are a number of places that this interaction can and should take place: the rubinius spec, future directions of Ruby, ruby conferences (regional and otherwise), and the Ruby blog-space. Peterson and I talked about this in an interview about Ruby.Net, and I believe he’ll work hard to make sure this comunication happens.

Who know’s maybe this is just the kind of shake-up the Ruby.NET community needs to get things moving again.

(By the way, I think the XRuby project is a remarkable parallel. They’re also aiming for static compilation of Ruby, and aren’t comunicating as well as the corresponding dynamic implementation of Ruby for the same VM. Maybe that’s a post for another day.)

Ruby.NET Interview With M. David Peterson

M. David Peterson came out to the UtahValley.rb’s ‘Ruby on .NET’ night to represent the Ruby.NET project a while ago. The IronRuby presentation ended up going longer than we’d scheduled, so I wanted to ask him some questions about his view on the two Ruby projects and Ruby.NET specifically.

---

How much are the IronRuby and Ruby.NET projects working together?

M. David As far as I know, there is no collaboration, something I would LOVE to see fixed, ESPECIALLY as it relates to the RubyLib’s themselves, as for what should be obvious reasons being enabled to use the various RubyLib’s via both Ruby.NET and IronRuby would benefit both projects as well as developers writing Ruby code targeted at the .NET platform.

Where/how could they better cooperate?

M. David The development of both the RubyLib’s as well as extensions to those libs would be the ideal collaboration point, in my opinion. One of the future pain points that is bound to come into fruition is the (ability|inablity) to use code targeted for Ruby.NET w/ IronRuby and vice versa. For example, making an external to the .NET Framework Class Library (FCL) should work exactly the same regardless of the runtime engine/compiler being targeted. If it doesn’t, both projects are going to find friction in the development communities as it relates to adoption of either platform.

To me, anyway, the two most important points for both the Ruby.NET and IronRuby projects are,

• Can I quickly and easily run my existing Ruby code, w/o change, via both runtime implementations?
• If I make a call to the .NET FCL in my code, will that code run the same via Ruby.NET and IronRuby?

What’s the easiest way to get started with Ruby.NET for Windows, Mac, and Linux users?

M. David Begin with a specific development task and then start writing the code to make that work. Attempting to get an existing Ruby library to run can be frustrating due to the fact that the Ruby.NET project as it relates to full compliance with the Ruby language is not complete. And the real key benefit to Ruby.NET is the interop layer with other .NET languages such as C#, VB.NET, IronPython, etc. So while there is still more work to do before full compliance with the Ruby language is achieved, there is still some amazing things you can do as it relates to using the Ruby language to build and extend from existing .NET libraries.

What are some ways the Ruby.NET team is working with the larger Ruby community?

M. David Let’s just say that’s a work in progress. ;^)

What more could they be doing?

M. David A lot! Joining in the efforts to ensure cross-engine interop is critical in my opinion, so taking part in the ongoing efforts to develop a test suite that ensures proper compliance is therefore critical.

In addition I think it would make a lot of sense to join in the efforts of defining the future directions of the language itself. .NET has a lot to offer when it comes to providing solid use cases for language features. I think the biggest mistake any language design team could make would be to ignore the fact that with .NET there is a HUGE base of languages and therefore language features to pick and choose from that could benefit them.

Why should we trust Microsoft?

M. David You shouldn’t. At least as it relates to whether or not MSFT will do the “right thing” when that right thing is a choice between what’s right for the development community and what’s right for their share holders. MSFT is a profit driven company and will make their decisions based on what will generate revenue and what will not.

But in the case of the MPL’d projects, you don’t have to trust them. The .NET open source communities are active and vibrant, the Mono Project representing the most active and vibrant of them all, filled with passionate open source .NET developers. If MSFT falls short on any of their MPL’d projects, the community will jump in and either fork the project and/or fill in the holes as needed. Seo’s IronPython Community Edition project is a good example.

Ruby is a community-based language, with several OS implementations already in existence. With the added value of being able to interop directly with a HUGE base of development languages, the benefits of continuing forward with the Ruby.NET project regardless of what MSFT might do is obvious. Of course Ruby.NET is completely independent of MSFT and as such, there’s really no reason to be considered with what MSFT does or does not do.