While many perceive Java as “that old language we used to build those super slow Applets with”, the Java Virtual Machine (JVM) is one of the most, if not the most advanced virtual machine in use today. While the Java language may not be the hot new language it used to be in the ’90s, don’t dismiss the JVM just yet.
Twitter certainly doesn’t. An interesting InfoQ article discusses the ongoing move of the twitter architecture to the JVM. More and more is ported from Ruby to Java and Scala:
We were originally a Rails shop, and I believe we are the largest Rails site in the world, but as we’ve grown as an organization, and as a service, performance and encapsulation have become very critical. I wouldn’t say that Rails has served as poorly in any way, it’s just that we outgrew it very quickly. So there are two things about Rails that make it no longer ideal for our situation. First, the Ruby runtime is slow, particularly in comparison to the JVM. We’ve worked hard on the garbage collector to get reasonable performance.
And also the LAMP model that Rails embodies, where you have a set of tiers each of which only talks to the one above and below, and no vertical encapsulation, doesn’t serve a large organization like us very well.
As we’ve been focusing on performance and encapsulation, we’ve fixed performance problems as necessary, with caches, or working on the VMs.
The majority of requests on Twitter go through Rails right now, but as we build new services, if we choose to build them from scratch, in order to achieve better encapsulation we move them into the JVM, because the performance concerns outweigh any sort of productivity or agility downside those languages might have. So when we re-built Tweet storage we built it in Gizzard as a homogenous service, it exposes a domain interface, and that’s a Scala system that partitions and manages uncoordinated MySQL nodes. So that effectively eliminated ActiveRecord use for tweets from the core Rails stack.
The same with the queue; when we wanted to rebuild it and re-encapsulate it for performance reasons we wrote it on JVM. So as those kind of lightweight, service-oriented projects proceed, more and more concerns are being taken out of the core Rails application.
The article also discusses static typing and Ruby MRI vs. JRuby.