I am also posting to disagree. In general, I have been pretty rough on Scala, but the long and short of it is something like this: Scala trades being a usable

I am also posting to disagree. In general, I have been pretty rough on Scala, but the long and short of it is something like this: Scala trades being a usable FP language for being good at Java interop. Everything you could want to do in Java (except for enums) is possible and usually significantly easier and more succinct in Scala. Everything you would want to do in OCaml, Haskell, or Scheme, is possible and usually extraordinarily difficult in Scala. > -- Scala advocates a completely different style of programming. You have to rethink how you code to match Scala's functional style. This is not a trivial thing if you have a bunch of Java developers you need to convert. Imperative Scala is both performant and readable. For the application I work on, in many places it is the only style that is sufficiently performant. > -- I find the Scala documentation is less readable than Java's docs. They are cluttered with type conversion functions and unreadable operator overloads (the filtering helps a bit here, but it's extra work). Documentation is also split between the object/class/trait pages. This is pretty much true. Good IDE support and #scala@freenode help. > -- There's a whole class of immutable data structures whose performance characteristics I need to learn, since I'm supposed to be using them. You can use whatever data structures you want, including the ones in java.util. If immutable data structures are appropriate for your application (for instance, because you want nondeterminism based on Scala's delimited continuations, and repeated invocations of the same continuation should of course see the same data, or because you want to pass a lasting view of the current state of your collection to another thread), then you can use them. > -- I'm not convinced that the overhead of copying immutable data doesn't outweigh the benefits of the ability to trivially parallelize the code. This is an objection to a particular way of structuring applications, rather than to a language. > -- I'm not convinced that a project preferring only immutable data is easier to maintain. This is also not a Scala thing. My insignificant industry experience indicates that it is true. More importantly, John Carmack seems to think so: https://news.ycombinator.com/item?id=6278047 https://news.ycombinator.com/item?id=6278047 > -- Programs seem to take longer to compile (sbt is especially slow). Yeah. I would be okay with this if I got the GLORIOUS TYPE SAFETY from it, but Scala does not really deliver on this front. > then you need to know all of Scala's features as well. This is a big burden, to be sure, and Scala introduces some unreasonable gotcha's along the way. Having already learned Scala, though, there's no reason I would sit down and write Java. Unless I wanted an enum.