I've heard a lot of the early adopters of Scala are moving away, including LinkedIn, Twitter, etc.
Some people from losing ecosystems like to spin it that way¹, but the truth is people are happy, adoption is great, and companies see that pain-points get addressed.
Of course there are companies which drop Scala, but often like in LinkedIn's case it's not caused by a dissatisfaction with Scala, but new leaders making different decisions like "we are using 10 different languages, we should consolidate on X and Y!".
The last unhappy company which is commonly mentioned is this social-network company Yammer. That was half a decade ago, and most of the issues mentioned have been addressed in the mean time. (Yammer has been bought by Microsoft, so it also made some sense to use a language that makes getting bought out easier.)
¹ I remember there was some very very bitter Groovy evangelist a while ago.
Kafka is deprecating their Scala clients because of maintainability issues as well. Scala keeps making breaking changes on dot releases, making it impossible to maintain long term.
The new Kafka client library is in Java just to reduce the number of dependencies, the server is still written in Scala. Strangely, using Java hasn't stopped Confluent from making breaking changes on dot release of the client... which really puts the lie to your explanation.
SBT makes it fairly straightforward to cross publish for different dot releases of Scala, and libraries in the Scala ecosystem do it all the time.
Scala dot releases are far apart. It's been over 2 years since 2.11, and 2.10 released in 2012.
By contrast, the JAVA client that the Kafka project published in November is already undergoing breaking changes for the current release candidate. It's pretty clear that avoiding breaking changes is not an overriding concern for them, and even if it is, it's equally clear that Scala was not the inherent problem.
Scala is developed by the EPFL, Lightbend, and ScalaCenter. That's three, not one.
> Scala keeps making breaking changes on dot releases, making it impossible to maintain long term.
That hasn't been true for more than half a decade.
Very silly.
That doesn't mean you're wrong; but it does explain the confusion. I'm a fan of Scala but I'll admit I was confused by this as well when getting started with it since I've been trained to see everything after the first decimal as "minor".
Apache Groovy has always been good for scripting stuff on the JVM, including for Grails and as a DSL for Gradle. Unfortunately, one of its backers tried to retrofit it to do static compilation, and pitched it as a alternative to Java instead of simply an accompaniment. That's when the trouble started. Groovy's static compilation can't be as good as that of a language designed from the ground to be statically compiled, e.g. Java, Scala, or Kotlin. To this day, Groovy's own codebase is still Java. Even though some people talk anonymously of "1 million line Groovy codebase where static compilation is required", Groovy's own "million line codebase" isn't statically compiled Groovy and until it is, any claim of such codebases is just a claim, nothing more.
Sure, companies aren't dropping existing code in Scala, but I would be surprised if large organization were to push for new code to be written in Scala instead of Java 8.
Edit: link
Of course you can write Java in Scala and then the benefits over Java aren't that high (but are still there), but Scala is so far ahead in terms of language compared to Java that most current Scala libraries just _can't exist_ in Java.
Adoption these days seems to be great and accelerating, and given the growth of the library ecosystem there are more and more reasons to leverage the benefits of libraries written in Scala especially compared to legacy stuff written in Java.
Source: I work there.