Groovy and Grails vs Scala, Why Twitter choose Scala? [closed]

Question

I have a very basic question: Why did Twitter choose Scala rather than Groovy to switch from Ruby? I think using Groovy is easier for the Rubyist or Javaman than Scala. Thanks.

Answer 1

While only Twitter can answer that, you're essentially asking the wrong question. You should be asking yourself what business or technical problem made Scala useful to Twitter.

In fact, if you read about Twitter's integration of code in Scala, you'll see that they didn't just toss out Rails; they built systems to support a portion of their application in Scala and refactored existing code to talk to services built in Scala.

At some point, their primary technical concern ceased to be about the web app itself and became more about messaging and notifications. Groovy and Grails wouldn't have helped them solve that problem much better (or perhaps ANY better) than Rails. Scala, and other functional languages, make it easier to reason about highly concurrent problems by minimizing mutable state. It provides an actor model for concurrency problems that makes it easier to scale certain categories of applications to multiple processors and multiple servers.

This is essentially the reason why you should have more than one tool in your repertoire. Some problems aren't as simple as storing data and presenting it. You can get pretty far with pure Ruby tools, but there are still some practical limits when dealing with problems that either need threading or distribution across multiple machines.

They might as easily have chosen Erlang or even F# given a different set of team members or motivations. But another web framework would have likely provided little benefit at a far more substantial cost when their problem wasn't really at the front end.

Answer 2

Maybe you can find your answers here: http://www.artima.com/scalazine/articles/twitter_on_scala.html

Paragraph "Reliable, high performance code" catches it pretty well :-).

Bill Venners: I’m curious, and the Ruby folks will want it spelled out: Can you elaborate on what you felt the Ruby language lacked in the area of reliable, high performance code?

Steve Jenson: 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. Another thing we really like about Scala is static typing that’s not painful. Sometimes it would be really nice in Ruby to say things like, here’s an optional type annotation. This is the type we really expect to see here. And we find that really useful in Scala, to be able to specify the type information.

Robey Pointer: 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.

Alex Payne: I’d definitely want to hammer home what Steve said about typing. As our system has grown, a lot of the logic in our Ruby system sort of replicates a type system, either in our unit tests or as validations on models. I think it may just be a property of large systems in dynamic languages, that eventually you end up rewriting your own type system, and you sort of do it badly. You’re checking for null values all over the place. There’s lots of calls to Ruby’s kind_of? method, which asks, “Is this a kind of User object? Because that’s what we’re expecting. If we don’t get that, this is going to explode.” It is a shame to have to write all that when there is a solution that has existed in the world of programming languages for decades now.