[jonathanapp]

Exactly. I've been researching Kotlin as a Java replacement at my company and would like to promote it as an all-around, traditional language. In my experience Scala is favored by language nerds (not derogatory!) and their code, while fabulously concise and clever, was largely unreadable outside of their clique and used paradigms that are bizarre to even seasoned developers.

[runT1ME]

I'm a Scala fan, so know that up front, but I don't think Scala is unreadable outside of language fanatics, but the language itself is definitely more complicated than Java/Kotlin/Go etc.

We've had a lot of success bringing people unfamiliar with the language (even with heavy usage of Scalaz) because we try to maintain the right ratio of "Scala experts" to "new to Scala". We end up with 1 to 7 more or less, and it seems to work well.

As long as there's enough resources to steer people away from writing ugly code, the payoff can be quite nice. I have never seen a null pointer exception, almost all of the issues we see in staging/dev are related to JSON/REST,and the only issues we've seen in production have been performance/latency related. Scala really allows us to narrow down the type of bugs we get.

[cutler]

Take a look at The Guardian newspaper's github repository for some professional Scala. It ain't pretty - implicits all over the place, liberally mixed with Cats and Scalaz. This is Scala's big problem - taken in isolation Scala-isms are comprehensible but it's the way the cleverness composes that leads to a big ball of mud. Add to that the tendency of Scala connoisseurs to throw-in Cats and Scalaz at every turn and you have a recipe for disaster.

[vvillena]

The problem with Scala is that it is so expressive and powerful that it is really easy to write unreadable code, especially when delving into the heavy functional side. Scala is the C++ of the JVM.

There will be programmers that want to use every feature all the time, and while this happens with every language, the most featureful ones suffer the most from this.

[dionian]

Yes, the problem with lack of clarity is more often than not the fault of the API designer, not the language. Non-traditional method names like ~%>$ or whatever should be done in a very clear and easy to understand way; if not, that's a feature of the language that was used poorly by the software engineer.

Scala actually has a very consistent and simple syntax which after some initial learning phase is very easy to follow.

The standard library on the other hand, like many APIs which are written in idiomatic Scala, can be difficult to understand, especially at first. I don't admit to understanding it anywhere near as well as I do the Java standard library.

But the issues with Scala in this area is more akin to finding issues with the Java standard library (there are tons!), rather than Java as a language or a VM (two other things which are also correctly referred to as 'Java')

One of the biggest humps I had when getting into Scala full time was getting my head around the fact that many of the features of Scala actually occur at compile time, which as a Java veteran was something that took getting used to.

[pron]

> Yes, the problem with lack of clarity is more often than not the fault of the API designer, not the language.

Well, a language that enables unreadable cleverness can be said to be at fault. This is why languages, like Kotlin, that follow the Java philosophy, intentionally try to avoid introducing primitive constructs (regardless of whether you believe they are "intrinsically" "simple") that give rise to such cleverness, even at the cost of what others may call expressiveness. Valuing expressiveness over readability (which I here define to be no-cleverness) or vice versa is ultimately a matter of personal preference, but it is a value judgment that's made by the language, and languages that differ in the priorities of their values are very different from one another. Just as the difference between a pure language that guarantees (for the most part) immutability vs. a language that doesn't (even though no one is stopping library designers from writing only pure functions) is big, so is the difference between a language that guarantees (for the most part) readability vs. one that doesn't.