Grab a beer. I did not intend for this to be as long as it is, but I geeked out a little. Hopefully you'll find this as entertaining as I did.

There is a coffeescript implementation that runs on top of the Rubinius virtual machine. Without getting too into why that tingles my geeky insides, that's pretty cool. It started to get me thinking about the future of Rubinius, languages and the forthcoming platform race.

Virtual Machines

All code manages to get compiled down to machine instructions. These machine instructions are based on the architecture of your processor but look a little something like this:

push ax
mov ax,4
iadd ax,5
mov out,ax
pop ax

Which is a simple x86 program that adds 4 and 5 and stores the result in a variable called out. This code is pretty much activating the processor at a gate level and can become very tedious to write. In order to become more effective programmers, we created compilers that would interpret more human-readable code. We created several languages but the most popular is vanilla C.

Just like modern languages, C was created because programmers were tired of writing things they didn't care about. In the C world, we didn't need to worry (much) about stacks and registers. When we wanted to do the above code, we wrote the human-readable version:

int out = 4 + 5;

More sophisticated features like functions, control structures and data structures allowed us to reuse code and deliver software faster.

Enter Java. In the mid-nineties the team at Sun began working on a new language. One of the language's goals was to be platform agnostic. They wanted to create a language that you could write once, run anywhere. The reason that this is not possible with C is due to architectural differences between processors. The machine code above works on x86 Intel processors but not necessarily AMD processors (or x64 Intel, for that matter).

Instead, they created an intermediate compilation process that would turn the human readable Java code into closer-to-machine-code Java byte code. It looks something like this:

iconst 4
iconst 5
iadd
iload_0

The byte code is fed to the JVM which will execute the bytecode regardless of processor architecture. This is the effect of putting a virtual machine as an intermediary. We now have a common platform that we can now compile one or many languages against. For a long time, Java was the only competitor in this space. It was initially slow but feature rich. Java adoption exploded with the web and now we are in a world where virtual machines are the new hot ticket.

Development of Virtual Machines

So, after a slew of backstory, we can now talk about what is happening today and tomorrow. Java, as a programming language, is a mess. It is overly pessimistic about the skills and knowledge of those using the language. It has far too much ceremony and is only bearable through the use of heavy IDEs like Eclipse, NetBeans and IntelliJ IDEA[1].

People have been innovating. They have taken advantage of the fact that the JVM can understand any Java byte code, no matter the source. Languages like Clojure, Scala and Groovy were created to make Java development more pleasing.

Some languages, like Ruby, were relatively infant in implementation of their VM. They leveraged the years of static code and garbage collection optimization that went into Java's VM. JRuby and JPython were introduced.

As this was happening, Microsoft began to see the benefits of language abstraction from processor architecture and the ability to leverage strong frameworks and libraries. They created the Common Language Runtime and published the Common Language Specification.

This allowed people (Microsoft, mostly) to develop new languages for the CLR. C#, VB.NET and F# all run on the CLR and are interoperable. Open source communities courageously sprung up to create IronPython and IronRuby though both seem to be sputtering.

Finally, the Mono team took on the monumental task of creating a competitor to the CLR and called it Mono. It fully realizes the VM's capability of running across multiple architectures and operating systems.

It started years ago but this race is starting to heat up. More attention and opinion will be throw around soon enough but here is my take on how things currently stand:

JVM

The JVM is clearly the 'front-runner' with several programming languages across multiple paradigms that are built on top of it. It has also been around for 15 years and has been a target VM for research and experimentation that inform today's and tomorrow's virtual machine implementations. It has the most sophisticated garbage collector in the group which ultimately affects the virtual machine's speed limit. Platforms cannot afford to hold on to dead memory for long and will be completely blown out of the water if they leak. Java also has years of research and momentum in terms of static code analysis. We cannot be completely sure, but its suite of optimizations are almost definitely best of breed.

Unfortunately, it is hamstrung because even though the JVM is an open standard there is threat of legal action to any competitive VM implementation (See: Dalvik and Android). Oracle's VMs are it and the Oracle JVM team is hemorrhaging smart and talented people. There will legal battles between Oracle, Google and who-knows-what-else in the years to come about the virtual machine. This could scare people away. If the legal battle is solved quickly, though, we may see a resurgence in the JVM from the Google and Oracle powerhouses.

CLR (.NET)

The CLR/Mono/CLS is another proven platform with the full force of Microsoft behind it. It has several languages delivered by the brilliant Microsoft Research guys and gals. It has had a dabble of ground roots support and development of languages such as IronPython and IronRuby. It is a long term investment for Microsoft and seems to be doing really well.

However, it sits behind Microsoft's bureaucracy and business goals. They have already effectively cut support for IronPython and IronRuby. While there are no definite answers, I can imagine that the reason behind those cuts are because it made no business sense to support competitor languages for the .NET platform when Microsoft owns the development stack for C#, F# and the like.

Really, they need to find a way to spark the OSS community. They are making a good start by letting enough alone and not pulling an Oracle on Mono. The Mono team has really stepped up in the year that it has been since I've seriously used it. They now support all core language features of .NET 4.0. There are some gaps in frameworks (and looking at that list, nothing I would list as critical) but Mono may be another avenue to prop up the .NET platform (somebody seriously needs to change the name, though).

Javascript

Javascript is really coming of age as a first class language. It is going through some growing pains. We're finding that Javascript is powerful, gives you lots of sharp language tools but can become a huge mess in the wrong hands. Tooling is rather weak. Javascript, though, could be the most used language in the world. Everyone has some sort of interaction with Javascript. Few, though, have interaction with Javascript as a first class language.

We currently have Javascript champions and wizards like Kris Kowal, Ryan Dahl, Douglass Crawford and John Resig that are trying to advance the language with specifications, documentation, tools and libraries. The Javascript interpreter is becoming blazing fast because of the Second Browser War. The next step is to abstract away from Javascript through either libraries (jQuery, ExtJS, SproutCore) or develop new languages on top of it (CoffeeScript, Objective-J). The community in the Javascript space is picking up momentum with early adopters and the cool kids. We will have to wait and see if the web as a complete platform can scale past initial enthusiasm.

Rubinius

Rubinius is the new kid on the block. It is a virtual machine that primary interprets Ruby code. It does, however, have an IR language that other languages can compile against. It is very new and is still attempting complete conformance to the Ruby specification. What sets Rubinius apart is its goals and development philosophy.

Rubinius was created as a platform for discovery and collaboration. The creators of Rubinius want to enable programmers to try crazy language ideas, visualize great optimizations and provide reliable implementations for their virtual machines. The JVM is locked up in the Google and Oracle castles, touched by the blessed few. The CLR is behind Microsoft's business wall. Javascript interpreters are in the hands of the browser teams. Language geeks have very few options.

Not only is the development model for Rubinius very open in process, it is very easy in practice. As much code as possible has been pushed to Ruby. Only a very small (and diminishing) core of C is at the heart of Rubinius. The idea is that Ruby is far more approachable and abstract as a language. Programmers can quickly try new ideas, visualize problems and solutions and leverage the great suite of tools surrounding Ruby (like unit testing! Silly C.).

This opens the door for experimentation. Coffeescript is now a compiled language on Rubinius. It has access to all ruby gems. Lua scripts can also be compiled and use coffeescript libraries. Sometimes things make you realize we live in a wonderful world.

Also Rans

There are a couple of VMs that I want to mention.

Parrot is another virtual machine. It has some interesting research projects that are constantly being tested against it but it has not yet enthused anyone outside of academia. As of their wiki, there are currently no "Production" quality languages that are in wide use. The Perl6 implementation is likely the most complete.

LLVM stands for Low-Level Virtual Machine. The LLVM is used by Apple in Objective-C compilation and also has support for languages like Ruby. However, outside of the Mac community, the momentum seems to have slowed. Being primarily developed by Apple, it would run into the same doubts as a Microsoft VM from a business perspective. It is also a bit of a misnomer because it is more compiler than virtual machine.

[1] This is my personal feeling about the language, of course. Many others share these thoughts. Many do not. Nevertheless, this is a large part why new languages sprang up on the JVM.