One VM to rule them all

I have been for the past weeks been thinking about the (broken) state of popular languages. Not that the languages themselves are fundamentally broken, no, not like that. Rather, the state of their lousy virtual machines. The machines that actually hinder their adoption. Paradoxical? Well, let me tell you.

Many developers are afraid of adopting young technologies and languages/VMs are no exception. Actually, requirements are even stricter with these type of products. Getting rid of a error-prone VM which is usually heavily tied to language implementation isn’t easy. People tend to think twice about the decision. Also, switching VMs usually requires the operations team to maintain and operate the legacy parts after you make the switch.

Second problem with all these DIY VMs is that they are slow. Painfully slow sometimes, often resorting to C to speed things. Ok, that’s fine you think. I don’t have to deal with that. “Other people” will provide me with speedy libraries of things I usually do. JSON encoding, image manipulation, database interaction and so on. And that is what has happened to Ruby and Python. Luckily, people actually spent the time creating these libraries for the rest of us. However, you find out that you sooner rather than later actually have to deal with this. Not only because your own code might be in need of that extra power but also for another big reason, deployment. Managing these C extensions is something that quickly can become dependency hell.

Consider an environment where you have developers both on Windows and Mac and servers running Linux. Handling this seamlessly isn’t pretty. Having things as PyPI/RubyGems colliding with native packaging tools such as RPM and apt isn’t exactly helpful.

Ruby and Python isn’t cross-platform

In theory, yes non-native code is. But in reality any application developed using these two languages are subject to the joys of C extensions. Lack of makefiles makes everyone happy. JVM and CLR really shines here. The reason they don’t have to deal with this is that their implementations are fast enough. Fast enough to not have to resort to native code for basic things such as serialization. Native extensions are actually frowned upon in the Java community. And for good reasons. The JVM has reached a state where it’s just the matter of dropping your JAR/WAR/EAR on to your system it will work. Guaranteed.

Every time a new language is born, another VM gets invented. Reinventing/reimplementing all common features found in modern VMs. Garbage collection, TCO, performance, multiple platforms and so on. Comparing these fresh implementations of VMs they cannot be anything but inferior to giants such as the JVM. Not to mention the lack of inter-operability between languages when home-baked VMs gets widespread. Sometimes, having multiple can actually be hurtful long term. Take Ruby for example. It’s a great language but having JRuby, MagLev, YARV, MRI, IronRuby, Rubinius and MacRuby can actually hinder adoption. Not because of the variety offered but of the duplicating effort. Effort that could be used taking the implementation forward rather than reimplmenting “the same old things”. Fortunately, I think Darwin will sort this out for us. Much like he will with key/value databases :)

Things are happening

In contrast to this there are languages designed from the ground up to run on a specific VM. Take Scala, Clojure, Ioke or Groovy for example. They all were specifically designed to operate on a mature virtual machine. Immediately taking advantage of the tools, libraries and infrastructure already in place at many companies. This offers great opportunities not only for adoption but for the JVM as a platform. Things like invoke dynamic is perhaps quicken by this fact. Who knows, maybe even TCO will? Let’s hope Oracle will do the right thing.

There are a couple of interesting VMs available today, that probably take on center stage as things move forward. The two most prominent are (of course) the JVM and CLR. Others, such as BEAM with it’s ideas of concurrency, will also take part. Server-side VM’s will go through a renaissance the coming years where we will hopefully see fewer implementations. But in return, these new virtual machines will be of better quality than those previously seen by different language creators.