Does Scala scale better then other JVM languages?

Question

Here is the only way I know to ask it at the moment. As Understand it Scala uses the Java Virtual Machine. I thought Jruby did also. Twitter switched its middleware to Scala. Could they have done the same thing and used Jruby?

Could they have started with Jruby to start with and not had their scaling problems that caused them to move from Ruby to Scala in the first place? Do I not understand what Jruby is? I'm assuming that because Jruby can use Java it would have scaled where Ruby would not.

Does it all boil down to the static versus dynamic types, in this case?

Answer 1

No, not really. It's not that the JVM is somehow magic and makes things scale by its magic powers; it's that Scala, as a language, is architected to help people write scalable systems. That it's on top of the JVM is almost incidental.

Answer 2

Scala is a statically typed language. JRuby is dynamically typed. That is why Scala is faster than JRuby, even though both run on the JVM. JRuby has to do a lot of work at runtime (method resolution, etc.) that Scala does at compile-time. For what it's worth, though, JRuby is a very fast Ruby implementation.

Answer 3

Scala is "scalable" in the sense that the language can be improved upon by libraries in a way that makes the extensions look like they are part of the language. That's why actors looks like part of the language, or why BigInt looks like part of the language.

This also applies to most other JVM languages. It does not apply to Java, because it has special treatment for it's basic types (Int, Boolean, etc), for operators, cumbersome syntax that makes clear what is built in the language and what is library, etc.

Now, Scala is more performatic than dynamic languages on the JVM because the JVM has no support for them. Dynamic languages on JVM have to resort t reflection, which is very slow.

Answer 4

There's an interesting discussion from the Twitter developers themselves in the comments of this post. They've evaluated the different options and decided to implement the back-end in Scala because: it ran faster than the Ruby/JRuby alternatives and they felt they could benefit from static typing.

Answer 5

I don't really think that the language is the biggest problem here. Twitter grew insanely fast, which always leads to a code mess. And if you do a rewrite, it is a good idea to go for a different language - that bars you from building your own mistakes again and/or to "reuse some parts". Also, Ruby is not really meant for that kind of heavy data handling that the twitter backend does. The frontend remains Ruby, so they still use it.

Answer 6

Scalability is not an inherit language capability. You are talking about speed.

A better question to ask would be "Why is Scala faster than other JVM languages (or is it)?". As others have pointed out, it's a static vs. dynamic language thing.

Answer 7

You have to separate out different meanings of scaling:

1. Scaling in terms of growing the number of requests per second that can be handled with a proportionate increase in hardware
2. Scaling in terms of growing a code base without it becoming a tangled mess

Scala helps on the first point because it compiles to Java bytecode that's really similar to Java, and therefore usually has the same performance as Java. I say "usually," because Scala there are some cases where idiomatic Scala causes large amount of boxing to take place where idiomatic Java would not (this is slated to change in Scala 2.8).

Performance is of course different than scaling. Equivalent code written in JRuby would scale just as well, but the slope of the line would be steeper - you'd need more hardware to handle the same number of requests, but the shape of the line would be the same. But from a more practical perspective the performance helps because you rarely can scale in a perfectly linear fashion with respect to adding core or especially servers and having better performance slows the rate at which you have to add capacity.

Scala helps with the second point because it has an expressive, compile-time enforced type system and it provides a lot of other means for managing the complexity of your code, such as mixins. You can write spaghetti code in any language, but the Scala compiler will tell you when some of the noodles are broken while with JRuby you'll have to rely solely on tests. I've personally found that for me Python breaks down at about 1000 closely related LOCs, and which point I have to refactor to either substantially reduce of the LOCs or make the structure more modular. Of course this refactoring would be a good idea regardless of what your language, but occasionally the complexity is inherent. Dealing with a large number of tightly couple LOCs isn't easy in any language, but it is much easier in Scala than it is in Python, and I think the analogy extends to Ruby/JRuby as well.