I'm not sure what you are looking for. Isn't your question akin to asking since Java just compiles to bytecode, what advantage is there to writing java instead of bytecode.
The higher level abstractions that are directly supported by Scala are precisely what make it more "scalable" from an authoring perspective. In particular, the amount of help it provides in writing many objects to support an OO design along with the functional support it has go a long way to reducing your code down to quickly communicating the abstractions you are using, and not the language used to describe them.
This is particularly true in a method body, where one can use inference to remove the types from the code rather well. With judicious use of map/etc, often changing the collection type you are using is reduced to a single change in the code, and not through every intermediate collection along the way.
As far as I know, Scala can't give you _better_ performance than Java, but I also can't see it being too far off.
I've never really seen the benefits of Scala. Everyone whines about Java syntax, but it's really not that bad. Verbose, sure, but it just doesn't seem like time spent typing is where my productivity goes. Maybe I'm just getting old, but I no longer care about language syntax as much as I used to. A preprocessor to give me Java 8 lambda syntax would probably solve all the issues I have with Java right now.
"A preprocessor to give me Java 8 lambda syntax would probably solve all the issues I have with Java right now."
That's one of the things that Scala gives you: the functional features are there now and have been for almost ten years.
Still, I know where you're coming from. I was a die-hard Java guy until I gave Scala a shot. I'm not looking back, though I do think that Java's tooling is much more mature than Scala's.
Scala has much worse tooling (SBT is an oxymoron), and it's much harder to read than Java.
Conceding that it's more fun to write, I think 'harder to read' is more important. Scaling refers to team size and amount of functionality in addition to requests per second.
The "much harder to read" varies greatly between codebases. Most "sane" codebases are 90% (random percentage) as easy to read as Java. Just collection initialization, transformations, simple pattern-matching, method invocations...
Some times there is an ugly nested flatMaps/maps/filters. But in my experience, in general, they're more the exception than the rule.
Scala compilation is indeed slow (although I think C++ is worse). But I always have a "sbt ~compile" running, compiling every file as they change. So the compilation time is pretty much irrelevant to me. While using eclipse, I guess, you'd get the same speed too.
I didn't either, until I tried it. On one level, yes, it's java with type inference and lambdas and saves you typing. When you dig a little deeper in scala, things like case classes (immutability), pattern matching, for comprehension (monad syntax) suddenly fundamentally change the way you program.
Code becomes a lot more clear, explicit, and... fun. I recently talked to a dev who used Akka with java for a network server, and he ended up coding it in 'an object for each callback handler' style.
When I asked why he did it that way, he said nesting callbacks to sequence operations would get too ugly fast.
This is trivial in scala. The language flaws in java ended up dictating the architecture of his entire application, and for the worse IMO.
I think the benefit is that people don't want to say they're Java programmers. It's like a hipster thing. Most modern scala programmers don't even use the language correctly, or couldn't write "hello world" if it wasn't in the play framework.
Off the top of my head, Immutability means less locking, which is big enemy of scalability; Actor Model support in the standard library also makes concurrency much easier to deal with. Wikipedia [1] mentions that Scala "actors may also be distributed or combined with software transactional memory".
Semantics aside, there is really no difference between performance in Scala and Java, equivalent code in both compiles to near identical byte code, save for a few niche optimisations (eg tail call recursion) that can make Scala faster. I discussed this here:
Since it's all just bytecode, then there's no difference in what you can do when it comes to scalability. However, it's the semantics, that you think are just personal preference, of Scala that make writing scalable code easier, it biases you towards scalable code with things like default immutability and using asynchronous io and things like that. Anything you do in Scala you can do in Java, but the question is, when the syntax overhead of for example monadic programming is over 5 times greater than the equivalent scala code (and many times less readable and maintainable), would you do that? Most developers don't. I wrote another blog post about that here:
> "language semantics since I believe that to be a personal preference"
If you start with such patently false beliefs you aren't going to get anywhere. Good abstractions are good, regardless of your personal preference. I have a very hard time programming without immutability, catamorphisms, pattern matching, sequence comprehension, varargs, fmaps/functors, partial functions, monads, predicates, filters, higher order functions, lambdas, closures, trampolines, continuations, strong types and co/contra-variance, options, actors, immutable collections, regex, combinators ( kestrels ), a dash of abstract algebra ( monoids semigroups groups rings fields ), basic math structures ( at a minimum, graphs with traversal algos baked in ), macros, implicits, dsl capability, and a mathstat library.
If you give me a language without some of the above, I will first invest time buying/building whatever is missing, so that I get that full list.
The claim is that scalability is an acronym for that list. If you give me everything in that list I give you scalability. Scalability is not about being close to the metal, gobs of ram etc...rather we are talking about the same block of code that services 200 million clients with the same sla/latencies as easily as 200 clients when you throw reasonable extra horsepower at it.
Without that list, you are essentially programming in the 19th century. You will, without even knowing, end up building various versions of these in your own pet language...for example, after writing a "for loop" with an "if statement" to vary behavior based on containment in a collection for the 100th time, it will occur to you that there must be a better way to encapsulate this logic...and sure that's what a predicate with a partial function is...but it's not like you are newton and you sit under apple tree and apple strikes your head and you get gravity out of it...these things won't come to you like magic...you have to essentially sit down and read a book on fp where they tell you why they do what they do.
The thing with scala is that you can pair it up with akka/breeze/scalaz & hit every single item on that list and then some. So also with haskell, clos, ocaml, sml, clojure, erlang...the match degree varies but you can get close to 90-100%. If you try to hit that list with a non-fp lang like c++/java...the degree is like 20% and you will have to do 80% of the work to hit that list.
Now you could say (as my manager at my former big-co did) I don't give a shit about that list above, maybe your list consists of only 3 things - personal preference, easy availability of devs from india for hiring purposes, and spending less money. Then sure, java is on the table, as is js, ruby, python, some subset of c/c++ etc.
One simple example of Scala power is the greatness of the Future pattern (scala, akka, finagle/twitter and other implementations).
You can still have the exact same Futures functionality in Java, but they will be so much more verbose and annoying to use that it ends up not being a good idea.
Strawman: you're reducing differences between languages to semantical differences and that's simply not correct.
Someone already mentioned immutability. Another example is sound concurrency support: a language which is using non-blocking synchronization is not going to have threads constantly blocked monitoring locks (I'm not talking about Scala particularly: but in Java the language, the "synchronized" SNAFU is really totally messed up if you've done any serious concurrent programming and it's very hard to get "right").
Then another example it's also a fact that crazy optimization can be achieved by using macro pre-processing at compile-time. Java the language doesn't offer this. It's actually so problematic in certain cases that there have been specific tools developed (e.g. by Nokia for accessing the J2ME Nokia API) that did add macro support to Java.
Another example where macro do shine: an API like trove, using primitives-backed maps/set, runs circles around, say, a normal HashMap{Integer,Long}. But Java cannot automate/duplicate the code needed to offer this for all the primites types (which, some may argue, is precisely the reason why such performant maps/sets have never been part of the stock Java APIs). So how do you do if you want to "run around circle" of these default totally lame HashMap{Long,Integer} like if you're say, the Trove author? You write your own code generator generating all the .java files needed from a template. Pretty cool (from the Trove author) but also pretty lame (from "Java the language").
With real macros this one is a no-brainer. So much for "semantics".
These are just two examples: you're belief that language differences can be resumed to semantics is incorrect.
I'm not asking about language semantics since I believe that to be a personal preference, rather scalability and performance.