Compilation vs. Interpretation for Ruby in VMs

In an earlier post I was talking about JRuby and IronRuby a bit. One of my thoughts was that we need to be able to run these Ruby-(or insert language here)-in-a-VM either interpreted – or to compile them.

JRuby compilation 

JRuby has AOT (ahead of time) compilation as of 1.1 which is in beta currently. I am not sure when it is ‘due’ but it seems like it will not be too far off. This way – if you want to make a jar out of some jruby files – you should be good to go.

.Net Ruby compilation a bit more complicated. There are currently 2 Rubies for .net – the (formerly Gardens point) compiler – that is a compiler for ruby – it takes .rb files – and turns them into an assembly. On the other hand - you have the IronRuby implementation being atop the DLR (dynamic language runtime – Microsoft.scripting runtime). IronRuby – as I can see it – is meant to run interpreted – through the DLR.

Neither IronRuby nor is not nearly as together as JRuby. Semantics for implementing interfaces are not there in, property style set/get is ugly (set_PropertyName is how it looks in the usage). You cannot use ‘classic ruby style naming (vs pascal naming that is prevelant in .net).

Here is a recent post ref’d off the mail group comparing IronRuby and

Anyhow – there is my current update. Microsoft seems to have done something really good with WPF – the rest of the world seems to be doing better in just about every other area. Vista seems to be an embarrassment… Ugh for MS.


Leave a Reply