Ruby for .NET? This is going to be interesting...

There have been a few bridging projects in the past that aimed at using .NET libraries from Ruby. Now, this is different, this is an actual implementation of the Ruby language for the .NET Common Language Runtime. Seeing how .NET finally seems to be more than OK with dynamic languages (see the amazing IronPython project), this could prove to be a very interesting turn of events. The open-source project, initiated by the Queensland University of Technology in Australia, is in its early phases with only some of the standard Ruby libraries implemented. This is not very surprising as the most difficult parts of porting a language is usually that the language itself is not enough, you also need its base class library if you need more than a familiar syntax and if you want that to have more than marginal usefulness. J# suffers from the same kind of problem with its class library.

Anyway, I thought I'd let you know. Check it out:


  • Wilco, so why not to join your forces with them?

  • Try Boo, Very ruby-esque and is supported (debugging, winforms development, refactoring) in SharpDevelop.

  • Mischa: if I'm not mistaken, this is a bridge between .NET and Ruby, it's not an implementation of Ruby on the CLR.

  • But a new language implementation is not what I would expect from Ruby... I would rather prefer an implementation of On Rails for .NET ... that would be great!!!

  • Yes it is a bridge, but I suspect that for the 80+% case this is what most people want - have .NET and Ruby objects seamlessly integrated in the same Win32 process. It will be *very* difficult to get a real Ruby implementation up and running on the CLR - the language is just so, well, dynamic. The bridge is already pretty usable now - I've built Avalon apps as well as Windows Forms apps (not to mention most of RubyCLR itself) using Ruby.

  • Bridges have not been trhat successful so far (no matter what the language is) so I really doubt that. IronPython shows us that it is possible to have a dynamic language perform very well in the CLR. Actually, I would express doubts the other way around: I doubt a bridge will utlimately perform well because it will have so much marshalling to do.

  • Bridges are not about performance. Neither are dynamic languages (necessarily). What dynamic languages buy you is the flexibility to write less code, and (hopefully) better algorithms because there's less language noise that gets in the way.

    Most apps spend most of their time not doing very much. Yes - there is marshaling that has to be done, but how expensive is the cost of marshaling some EventArgs into a Ruby block in a UI-based app that runs on a processor retiring several billion instructions per second?

    It's not that I haven't paid attention to performance in my bridge; if you take a close look at the implementation, you'll see that I don't use Reflection at all at runtime - instead I generate compiled CIL shims that do the marshaling in the most performant manner possible.

    Burn the CPU cycles in the name of programmer productivity - I make it trivial for folks to use native CLR code in their app wherever it is warranted.

  • John, don't take this the wrong way, I'm sure you're building a great and useful product. It's just that I'm more convinced by a full CLR implementation of the language than by a bridge. I wish you a great success with your project.

    And yes, it's all about developer productivity.

  • Yes Yes Yes! Just look at IronPython and how well it works. Why would Ruby be any different?

  • IMHO, using their own PE writer is a big mistake for such a dynamic language as Ruby. If perfect for batch compilers, it's not very well suited for dynamics language where Reflection.Emit and LCG rocks.

    At each assembly emitted, they will have it twice in memory...

  • As I understand it, Reflection.Emit does a number of other things beyond generating PE files (such as performing verification). Our PE writer performs only the work that is required.

    And just because Ruby is a dynamic language, doesn't mean it can't be compiled.

    Only features such as eval require the compiler to be invoked at runtime, and Ruby programmers already expect eval to be slow.

    We may very well have performance issues, but I doubt our PE writer will be the most critical.

  • Here's Ruby on linux. Live. Unabridged. Open. Fine-tuned. Also works on Mac OSX or any other unix. Get a life.

  • Dear Ruby, thanks for your suggestion to get a life, but I already have one and I suspect it's more interesting than yours seeing how you waste your time on such comments.

  • Well, seems I was censored first time, so let us put it mildly now.
    I know Ruby is a great success and has a good web framework called Rails, well, I still don't see the reason for such a brouhaha, given Ruby's similarity to Smalltalk.
    Clever guys knew twenty years ago that dynamic languages are good, hipsters just need all those "Rails" and "pragmatic programming" books and websites to jump in.

  • My2Cents: you were not censored by me. Maybe you got filtered by the automatic filters the first time. I didn't see another comment from you.
    I don't think I'm making a brouhaha, but it's more exciting and interesting from my point of view to see Ruby being adapted to .NET for two reasons. First, it hasn't been done before. Second, Ruby is being immensely more successful than Smalltalk ever was so having it for .NET is just more significant. I'm not judging in terms of quality, just in terms of success and reach. Maybe there's a reason why Smalltalk never really took off, by the way?
    If you need Smalltalk for .NET, it seems like there are already several implementations:

Comments have been disabled for this content.