Twitter on Scala

    Поверх JVM может работать множество языков. Не только Java, но и Fortress, X10, Groovy, Clojure, Scala, Jython, JRuby, etc. С недавних пор наиболее критичные части сервиса Twitter стали переписывать на Scala. Одна из причин - в JVM лучше чем в Ruby реализована работа с потоками и использование памяти. [http://www.artima.com/scalazine/articles/twitter_on_scala.html]

    "One of the things that I’ve found throughout my career is the need to have long-lived processes. And Ruby, like many scripting languages, has trouble being an environment for long lived processes. But the JVM is very good at that, because it’s been optimized for that over the last ten years. So Scala provides a basis for writing long-lived servers, and that’s primarily what we use it for at Twitter right now."
    "Also, Ruby doesn’t really have good thread support yet. It’s getting better, but when we were writing these servers, green threads were the only thing available. Green threads don't use the actual operating system’s kernel threads. They sort of emulate threads by periodically stopping what they are doing and checking whether another “thread” wants to run. So Ruby is emulating threads within a single core or a processor. We wanted to run on multi-core servers that don’t have an infinite amount of memory. And if you don’t have good threading support, you really need multiple processes. And because Ruby’s garbage collector is not quite as good as Java’s, each process uses up a lot of memory. We can’t really run very many Ruby daemon processes on a single machine without consuming large amounts of memory. Whereas with running things on the JVM we can run many threads in the same heap, and let that one process take all the machine’s memory for its playground."

Scala - это actor-based language, но в ряде случаев разработчики предпоситают старые добрые блокировки Java.
"But for other parts we’ve just gone back to a traditional Java threading model. The engineer working on that, John Kalucki, just found it was a little bit easier to test, a bit more predictable. The nice thing was, it took minutes to switch code that was actor based over to something thread based. It was a couple of search and replaces. So it’s not so bad if actors fail you for whatever reason."
"I ran into the same thing in Kestrel, the queueing system. I started off with an actor for every single queue. I found that the work is so fine grained there that it was actually better at that tiny level to just use Java locks. Actors work great for having client connections, where there’s a bit of work overhead to what the actor is doing, and the code for handling client requests is very simple and straightforward."