[jvican]

There's a tension between people using Scala for pure FP and people preferring to opt into pure FP whenever the model domain is needed, or that don't care about tracking every effect in their program and just focus on the 80/20. There are also those that use Scala for data science and other use cases for quick prototyping.

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.

[minerals29]

>The good thing about Scala is that it's flexible and it allows you to use it for your use case.

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.

[jvican]

> on that it should be either functional rather than something in the middle.

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.

[hota_mazi]

> 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.

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

[jvican]

No, you're misreading that announcement. The Scala team is working, today, on improving Scala 2.13.x and improving the migration and tooling path to Scala 3, as I said before. The fact that 2.14.x won't be release has nothing to do with the fact that there's a team of 5 or 6 people working on Scala 2 today.