Scala 3.0.0-M1

The crucial point here is if Scala 3 maintains backwards compatibility with Scala 2.x. If not, it's effectively a new language and then the game becomes which of the existing scala code bases will switch over and when. There's a large amount of existing Scala code out there and embarking on a migration of that stuff is going to take very long. We're talking many years here potentially. The few Scala projects I've dealt with, even updating to minor releases of Scala was a big deal.

The python 2 to 3 transition took well over a decade. You have similar discussions in what remains of the Perl community around v5 and v6. IMHO what Oracle has been doing with Java in recent years is impressive in the sense that they provide a credible upgrade path and put a lot of effort into that while still adding non trivial new language features. But it has a price of added complexity or compromises with new features and unfortunate legacy features that are not going to way. Javascript and typescript have the same issue. Javascript has a lot of weird legacy features and typescript preserves backward compatibility with that weirdness and attempts to engineers around that.

I'm currently using Kotlin across Android and Server (mostly) with an intention to also use it on IOS and Web very soon. Its multi-platform capability is increasingly a good selling point and I love how that ecosystem is booming in the last year/months. I'm definitely an early adopter of multi-platform but this seems to be one of those things where it seems like a bet worth making at this point.

Kotlin is of course a much younger language so it does not have a lot of legacy yet burdening it. Yet, Jetbrains seems to be good at managing new features while minimizing disruption, dealing with necessary deprecations, and generally not breaking compatibility. Their experience as tool makers gives them a unique edge over a lot of other languages.

Arguably Kotlin emerged as a rejection of Scala to replace Java by Jetbrains: they considered it and dismissed it as an option and then embarked on a journey to create their own language. I think the success of the language (relative to Scala) seems to indicate that that wasn't a bad choice. Scala intended to do many of the same things but it just never caught on with people actually doing those things to the extent that Kotlin seems to be catching on. The transition from Java to Kotlin is a lot less of a hard sell than the transition to Scala was. Though I know plenty of people that stubbornly stick with Java still. Of course early adoption in the Android community was a big deal. But then you could argue that that same opportunity was there for Scala to take and I don't think much serious effort ever was put in that notion. The need for something else than Java was quite big there and a big driver for this. All Kotlin did was provide a credible upgrade path to Java developers and the Android community jumped on it because it was easy to switch and obviously better. You see the same happening in the Spring community which is increasingly Kotlin centric.

Meanwhile Scala seems to be bleeding mind-share to more pure (for lack of a better word) languages Crystal, Elixir, etc. or more system oriented languages like Rust, or indeed Kotlin. It's a bit of a repeat of what happened to the Ruby community a few years ago. Certain types of people were very passionate about that language for a while and then moved on.

I really enjoyed writing Scala code. I'd agree with your evaluation with respect to the expressiveness and power provided by the language.

...but the tooling, at least at that time, was terrible. SBT was terribly overcomplicated, and full of foot-guns. I spent far too much time debugging dependency collisions, issues created by so-called "autoplugins" and other nuances that had nothing to do with getting real work done.

Now I'm writing a lot of Go. I'll admit, it's not nearly as fun to write. There's a lot less creativity and expressiveness -- though I think this is probably a good thing. But it also feels like I'm getting a lot more stuff done, and the tooling is amazing.

> Too bad there's not really a ML/AI ecosystem around (besides Spark, which seems to be losing favor partially because of its embarrassing performance)

Compared to what? If you mean engines like Presto, I would say they have different use cases, plus Spark SQL puts them roughly in the same ballpark. Genuinely curious though, as a Spark user that is always interested in alternatives.

>Too bad there's not really a ML/AI ecosystem around (besides Spark, which seems to be losing favor partially because of its embarrassing performance), because using Python is such a drag.

Even if Spark might not be the best tool for ML, it is still the tool to beat for data processing and custom ETL.

How is that a bad thing? It's the same in other languages and it is nice to have some flexibility.

E.g. lisp: use whichever type of parentheses you want

Or Kotlin: use short syntax lambdas fruits.filter(it == apple) or long syntax fruits.filter(fruit -> fruit == apple) or with annotated types: fruits.filter{fruit: Fruit -> fruit == apple}

Sometimes brevity is good for the reader, sometimes more details are good for the reader. Not everything is a nail.