7 ms·
After some deliberation, we decided on a JVM-oriented stack. The JVM is not without its quirks and challenges, but it’s a mature platform with well-known perfor
by thwarted 16y ago
After some deliberation, we decided on a JVM-oriented stack. The JVM is not without its quirks and challenges, but it’s a mature platform with well-known performance characteristics and a vast archive of libraries, particularly in the financial services world we find ourselves in.
We use the JVM in a non-traditional way. Our backend services are written in Scala, Clojure, or a mix of the both (making use of a thin compatibility layer we’re developing). Our web frontend is written in Ruby, and can be run on JRuby in production. This polyglot programming approach allows us to leverage the strengths of each language while still operating on a common platform. One could argue that it would be simpler to pick one language and stick with it, but that presumes that all problems are equally well solved in any one language.
Other than the vast archive of libraries, which are not necessarily going to be straightforward or similar to use across the languages on the JVM, one could still leverage the strengths of individual languages while still operating on a common platform, such as x86_64. Does the addition of another abstraction layer that provides the same interface (the languages) but that you don't really interface with directly really have that many (significant or otherwise) advantages?