I have been happily coding Scala for more than three years now. Just recently, I started a gig at another company; a company that is considering Scala, but hasn't decided yet. Let me give you my perspective, as an outsider.
Arguments in favor of Scala
- It allows you to write code that is easier to read (but it doesn't guarantee that)
- It tends to be more compact, by dropping the need of boilerplate code
- It might spit out bytecode that is executing faster, since it doesn't force you to rely as much on reflection for writing compact and generic code
- It offers a low bareer to entry to learning more about functional programming concepts
- These functional programming concepts definitely make Scala better at leveraging the cores on your systems
- It has everything you could ever wish for, and more -- which admittedly is not an argument in favor
- It has a solid foundation
- It's not PHP
What the opposition says
Scala is hard
I'd rephrase that into saying that Scala is a deep and powerful language, and that some parts of it are definitely hard. You might hurt yourself when going in too deep. Things that are normally the domain of language builders are accessible to all developers. Scala gives you a lot; it also gives you a lot of rope to hang yourself.
Now the question is how to deal with that. I want my kids to grow up and be safe. However, there's a lot stuff that could happen to them. They can fall off their bikes, choke in their muesli, fall from a tree when climbing it. One solution is to never let them bike, feed them fluid food only and forbid them to ever climb a tree. However, if I do that, they will ① be completely isolated (all their friends ride a bike), ② be unhealthy and ③ never learn to deal with risk themselves.
As a parent, the thing you need to learn is to allow your kids to make their own mistakes. That's the only way they will ever learn to deal with risk in their lives. You learn them to drive their bike really well, you learn them to chew their food and you learn them to be careful when climbing the tree. In all cases, you make sure you're around, to warn them if they don't see the risk, to pick them up if they fall, and to perform the the heimlich maneuver if they choke. In some cases you give them better tools to make sure they're not overexposed to risk. (Like, you buy them a helmet, or give them a smaller spoon.)
I think the same applies to Scala. If you want to prevent people to hurt themselves doing risky stuff in Scala, you first of all make sure they learn to use the language well and to be careful. You also make sure there are people around who've dealt with it before. And you sometimes give them tools to make sure they are not over exposed to risk.
That's the way you grow responsible adult software programmers. Telling them to stick to Java is like telling them to stick to Duplo. Duplo is great. However at some point you're done learning. I'm sure you an build everything in Duplo, but it's definitely not always the right tool for the job.
You will notice that I'm trying to avoid to limit the discussion to Scala alone. That's because I think good programmers will at some point innevitably decide that something is not the right tool for the job, and for a reason. They are dealing with code on a daily basis. They will notice that something doesn't fit like a glove. They need to be empowered to do the right thing.
Supporting multiple languages is deployment nightmare
That's easy. For Scala, it isn't. It lives on the Java VM. It's getting turned into Java code. For all the VM knows, it's just Java code written in a particular way, using an extra library. Your deployment platform doesn't need to be changed.
Supporting multiple languages is a resource allocation problem
First of all, developers are not resources. They're not. They are humans. A developer is not a field replacable unit. It's not like a hard disk: if one fails, you just replace it by another one. Since they are human, replacing one developer with another will ALWAYS have an impact, even if they use the same language. You are changing the team dynamics. The outcome is uncertain. Deal with it.
But you're right: if some people in your organization write Scala code, others might not necessarily be able to read it and work with it immediately. So, yes, you loose some.
However, people love making their own choices; not being able to make their own choices will make them leave your company. So you planned to avoid a resource allocation problem, but now you've introduced a resource allocation problem of an entirely different magnitude.
Scala is immature
Scala is not immature. Tool support is fine. There's a substantial number of adopters. It has been around 10 years.
There's no Scala library for x
That's true. Scala doesn't have libraries for everything that you would ever need. Java doesn't even have that. But then again, Scala doesn't need to have that. It's perfectly fine to mix Scala with Java libraries. In fact, that's what I have been doing continuously. (And in fact: that might actually be a good idea in some circumstances. I'll admit that Scala libraries are not always completely build around the 'API design in bumper stickers' rules.)
It jeopardizes investments
It doesn't. Other than the source code, everything in Scala is Java.
It's not node.js
Final thoughts: what happened to courage?
Extreme programming had four values: communication, simplicity, feedback, and courage. In many companies, I see three of them implemented. But what happened to courage? From my point of view, there's only one thing that's worse than choosing Scala or deciding to stick with Java: not deciding anything and keep discussing it.