The interests of all of these parties are different and that's what sometimes causes tensions, but these tensions do also exist in other programming languages that aim at a broad audience. Just look at Rust. Languages that do not show these tensions are languages owned by only one party (most of the time, a company) and that are the only stewards of the project and those controlling the agenda. The good thing about Scala is that it's flexible and it allows you to use it for your use case regardless of whether the language designers want to support your use case or not.
Your claim about Scala tooling being outdated or outright abandoned is not true. There has never been as good tooling as Scala has today, with a lot of innovation happening in the field. The reality is that Scala has really good tooling, on par with that of Kotlin and Java, and sometimes even better. Just look at projects such as Metals, Scalafix, Ammonite, mill, bloop or Scala Steward to get an idea of what I'm talking about.
Also, the Scala team is not working on Scala 3, Martin Odersky's team at EPFL --LAMP-- is. The Scala team at Lightbend is working on keeping improving Scala 2 and making sure tooling is still as good as it gets for when Scala 3 is finally released.
There are lots of people in the Scala community that are not so much into "FP language theory" or category theory and just see its potential as a cross-platform language to prototype and write robust software.
It's always tempting to agree to language X being flexible to suit everyone's needs but I would agree with John A. De Goes on that it should be either functional rather than something in the middle. Being flexible is only good on the surface, once it comes to actual daily work like reading other people's code expressiveness quickly becomes a burden.
>Your claim about Scala tooling being outdated or outright abandoned is not true.
I might have been trapped in my own little domain of data science guy and I don't know about other cool active libraries but whenever I dig something useful, it appears to be some PhD project left-overs or "last commit 5 years go" case. It's frustrating and doesn't encourage you to proceed working with the language.
So, if I ask, how does Scala future look like now that we have Java keeping up the pace with Kotlin basically sweeping the JVM newcomers and even Clojure looking good? I go read the Scala 3 goals and struggle to feel the same excitement over intersection types, better implicits, union types, type lambdas, DOT calculus of all things and all this at the cost of "Scala 3 won't be binary compatible with Scala 2" :) I am sorry but doesn't it look like a neck breaking academic crusade into oblivion? I think it does but time will tell of course.
I don't think the same thing, and other people developing the Scala language don't either, so it's a respectable opinion but tells you very little about what Scala is and will become. Scala 3 is catering for the Pythonistas and there are lots of important fixes that make the language easy to use for them.
The reality is there are lots of languages that are flexible. The important part is where they are flexible. In Java, you can do pretty much anything you want at runtime. Same with Ruby or Python. You can actually do pretty complicated stuff that screws up local reasoning about the code.
Scala is flexible at compile-time by having an expressive language. Some of this expressiveness has been sacrificed in Scala 3 to make the language simpler. But the foundational stuff stays there and time will tell how successful this release will be.
On your comments of Scala 3 and Scala 2 being binary incompatible, maybe you have missed all along that there will be no binary breaking compatibility with TASTY and the goal is that you will be able to mix Scala 2 and Scala 3 code within the same codebase.
> I might have been trapped in my own little domain of data science guy and I don't know about other cool active libraries but whenever I dig something useful, it appears to be some PhD project left-overs or "last commit 5 years go" case.
Again, check out the tooling projects I've mentioned before. Many of them don't either exist in other languages. I don't know what you're referring to with some PhD tooling project. I've been in the business of doing OSS tooling for Scala and working on the compiler toolchain for a long time. If your definition of "useful" tooling includes projects such as LMS, which was a research project, then there clearly is a mismatch between what good and useful tooling is for you and for me.
This is not true at all, Scala 2 is officially abandoned with the entire team now focused on Dotty [1]:
> we have decided that, rather than developing Scala 2.14, our efforts should go to Scala 3 instead.
[1] https://www.scala-lang.org/2019/12/18/road-to-scala-3.html
Also leaning toward FP is not theoretical zealotery, FP really helps to create more robust software (no null, better error handling, better concurrency).
(by the Scala.js maintainer Li Haoyi)
With Kotlin you get like 80 % of the good things from Scala for 20 % the efforts.
I've switched from Scala to Kotlin 3 years ago and didn't miss much (real pattern matching come to mind).
Of course it is still much smaller than Java, but Clojure can also be hosted on JS, BEAM or .Net. There's even a way to interop with Python and R.
Clojure is one of the nicest [production-ready] languages out there. It's pretty cool what it has achieved, with pretty much zero marketing effort and without support from big companies.
Scala suffers due to bad tooling. As somebody else said.
I'd still urge people to try out scala as a much better typescript (scala.js) for web
It'd be good if the OP elaborates on what "bad tooling" we have in the Scala community given that today Scala's tooling is good and on par with that of Kotlin and Java.