OK, so you work with Scala on personal projects, daily. The issues you bring up then are based on your own experience, and presumably not various postings on the net about Scala, fair enough.

So, what do you actually mean when you say, "The language is big (as big as C++) to the point where you must agree with your team on which subset to use"? Like you, I work in Scala daily and have never thought, shit, oh no, here we go again, the dreaded subset problem.

"It's so big that nobody can agree on which idioms actually to stick to: pure immutability? Functional style? OO only? Use scalaz or not?", use it exactly like Java...until you don't. Scala is not Python, there are many right ways to use the language.

The Scala-is-slow mantra is trance inducing, I agree, you just hear the phrase and voila, it's slow. Modular development (i.e. sub projects) largely mitigate the Scala-is-slow noise. Incremental builds are of course snappy, scalac and SBT have made great strides in this area, and SBT 0.13 furthers this trend (debunking the "getting worse at each version" nonsense).

According to Odersky Scala 2.11 will include [paraphrasing] aggressively stripping out unused/extraneous language features and improving compilation times.

Agreed on IDE support, it will come around, ScalaIDE has improved a ton during the past year (avoiding Juno helps).

I see the Scala glass as neither half full, nor half empty -- it's overflowing, future is bright ;-)

We used Scala in production at my previous job. It was great for the most part, but upgrading from 2.9 to 2.10 was a massive, massive pain. I think I spent nearly a week on the refactor. We didn't even have that much code (relatively speaking); the majority of the time was spent on finding substitutes for the libraries which were irreparably broken, and rewriting client code against the new API. That's pretty damning, but we could have avoided the upgrade if the team had better communication, so I see this also partly as a human issue.

That being said, I would be willing to use it again. I didn't have an issue with compilation speed, and the size/flexibility of the language wasn't really a problem; we wrote in what I believe is the idiomatic Scala style (immutable objects, FP). Going back to Java now, I SORELY miss lightweight lambda expressions, pattern matching, native Option type (that people actually use), and the emphasis on immutability.

Version compatibility is definitely a pain point, but as painful as that is I'd still pick that over using regular Java.

Can you give some details what caused the issues in your the 2.9 -> 2.10 migration?

To be honest, I don't remember the technical specifics...too much time has passed. It wasn't so much that a breaking feature change required rewriting code as it was that a single failure propagated. One component written in Scala on which my project depended was upgraded to 2.10, and a backwards-incompatible change in case classes broke the ability to serialize/deserialize objects between my project and the other component.

Upgrading my project to 2.10, several of the dependencies no longer compiled. I don't remember which ones specifically, but I believe one of them was a JSON library. We had to find libraries that fulfilled the same roles, then rewrite the code that used those libraries against the new APIs. It wasn't horrible in the sense of there being a nasty, hard-to-detect runtime bug, rather that it required basically redoing all of the "glue code" with respect to libraries.

This wasn't painful enough to scare me away from Scala in the future, though it does make me leery of using Scala libraries from anything but top-tier vendors. That is, I'd use a library from Twitter, FourSquare, TypeSafe, Akka, etc. but never again from anything not widely known.

Speaking as someone who uses Scala everyday for a largish organisation lots of this just seems wrong or irrelevant.

Poor tool support: I haven't had issues with IDEA refactoring

Backward compatibility: upgrading apps is usually not too hard, and from 2.10 onwards BC shouldn't be such an issue

Slow compilation: if you are working on very large programs anyway I feel sorry for you - we try and keep our services small and simple and compilation time isn't an issue

Language is big: depends what you compare it to. But choosing a subset doesn't seem necessary. Just make sure people have read one or more of the various good style guides around (the Twitter Effective Scala one for example, or Odersky's recent talk from Scala Days)

- Ibid. You should be using a functional style, but leveraging OO (case classes really). Although I do sympathise that Scala is more complex here.

Some of the points you raise have merit (mostly the ones related to complexity) but unless you are using a Lisp they are almost certainly true for your alternative language (such as Java, C++ etc.).

But lots of people successfully use Scala everyday at work. The organisation I work for has pretty much moved entirely to Scala now (from mostly a Java base) and we have about 60 devs. So it definitely can be done. And I haven't found a single person who wants to go back to Java.

> - Poor tool support (refactoring regularly broken on both IDEA and Eclipse).

You could file bug reports with Jetbrains to have them fix any issues you can reproduce. They're generally pretty good at following up and working on bug reports when I have filed them myself.

Alternatively, tell me what the particular bugs are and I'll try to reproduce them myself and then file a bug report(s) if you don't wish to. I use their Scala plugin quite a bit and while I don't think it's quite as good as their Java support yet, it's the best I know of for a Scala IDE.