It was before this: It was never a huge community, but from very early on it was split thanks to some rather unfriendly, competitive personalities and very different goals. You didn't just use scala: you either ran scala with a Twitter stack, or a typesafe(now lightbend) stack, or a scalaz stack, or a cats stack, or a zip stack. And a lot of the people developing each stack didn't like each other. I've gotten to work with core contributors of multiple of those, and knowing that I wasn't a devotee of any stack led to hearing way to much complaining in pairing sessions about how The Others (TM) were slowing down the adoption of the language.
A language that is really popular can manage having 5 ways to do things, but a small community is just going to lose steam. And the fact is, all the ways work just fine in a vacuum, but you can't just get really mature tooling when everything is just so split.
Yeah, I think with a community as small as Scala's, you can't really afford:
a. fragmentation of the ecosystem
b. repeated shuttering/abandonment of some of the most popular options (Lift, Play, Akka)
c. splitting the language in two
The perception within and without my own employer (which heavily invests in Scala) swapped from "acceptable" to "this ecosystem is a dead-end and we need to get out" with the launch of Scala 3. It's possible they would have reached the same conclusion, but I don't think breaking every industry engineer's development tools for years is a good strategy.
I don't think it is a problem with Scala 3 itself. Scala 3 brought a lot of improvements, one of them is using semantic versioning. People used to complain a log about binary compatibility between versions in 2.x. Now it's here.
I think that the slow adoption of Scala 3 is mainly due to one of its most successful projects: Apache Spark. To this day, Spark only supports Scala 2.13 although Scala 3 has been around for years now. This is both disappointing and frustrating because a lot of people were introduced to Scala thanks to Apache Spark.
The language is actually really nice. The "we won't ship dotty as the next version of Scala, just kidding, here it is", the breakage of editors and IDEs that lasted for years, etc (aka, the WAY they did it) make migrating a poor value prop. If I have to suffer worse tools and pay the tax of fixing them/updating them, then for each system when I think it's time to migrate to Scala 3 I might think it's time to migrate off Scala entirely.
It's possible that nothing could have reversed their existing trend, but I think it's fair to say that smaller communities (as another poster mentioned) can't afford this level of friction. Have we not seen Perl->Raku? Python2-3?
Additionally, while almost all of Scala 3 is an improvement over 2, whitespace significance seems like an awful hill to die on. Most people who value that sort of syntax in domains where Scala has made any inroads are already on Python, and we're going to alienate many existing developers in the (vain) hope of increasing marketability?
What really obliterated Scala’s momentum was PySpark overtaking Scala Spark coming from Python’s foothold in Data Science, columnar data warehouses carving out a big chunk of the batch processing pie as well, and then the Akka licensing change.
The Enterprise ecosystem quickly withered away, and now only type level programming diehards remain.
Akka's demise started before the license change. It's an incredible piece of software but as it turns out, not so many people need stateful cluster sharding. Modern cloud architecture and simpler streaming libraries have made the Akka toolkit irrelevant to many use cases.
You're right about Spark and the next logical step will be removing the JVM from the equation entirely, which is already ongoing (see Photon or Comet).
I think realistically we're looking at a lot of causes (which is not surprising; it's rarely a singular thing). Scala 3's momentum may have already been negative but how Scala 3 landed represented a nail in the coffin for a lot of individuals, teams, and organizations.
Scala 3 really landed at a bad time as the hype behind Spark, Akka, Play had already weaned off. Typesafe was struggling financially, and didn't back Scala 3 then (that went to VirtusLab).
Typelevel and ZIO really put a lot of effort to release many libraries on day 1 despite the hurdles with the 3.0 release, because these communities are alive and healthy. Yet Odersky is on a small crusade against monadic effect systems, which discouraged a lot of good people. On top of that there are neverending feuds and US politics...
Why is that? I think they did a lot of things right. Offer automatic conversions, backwards and forwards compatibility from a sufficiently recent 12.x version.
I think mostly Kotlin being simpler and Java gaining features ate the lunch. Also, software like Akka and Spark becoming less prevalent hurt because they were big reasons for devs to learn the language. Not to mention the community drama.
The only bad thing was that it took quite long for Scala3 to become available leading to a lot of stagnation.
From my perspective the two biggest challenges of the Scala 3 migration were macros and poor tooling support.
Macros were an experimental Scala 2 feature, but were used all over the Scala ecosystem. Because they were considered experimental a good migration story for them was never developed. That lack of support stopped migration efforts dead in their tracks at our company for a long while. It just wasn't worth contributing simultaneous support for Scala 3 and Scala 2 macros to every third party dependency who used Scala 2 macros. That said, we did it for some and lived on a fork for others.
IDE support for Scala 3 was really rough when it first released. We checked in on it with every IntelliJ release for roughly 3 years before we decided it was far enough along. Prior to that it was rough enough that we froze migration efforts in order to keep the tooling usable enough for engineers to be productive.
> IDE support for Scala 3 was really rough when it first released. We checked in on it with every IntelliJ release for roughly 3 years before we decided it was far enough along. Prior to that it was rough enough that we froze migration efforts in order to keep the tooling usable enough for engineers to be productive.
Same story for us - about 3 years before Intellij was usable, even then not up to what it had been on Scala 2. We still only have 2 Scala 3 repos, out of about 30, for my team, and we're actually MORE adventurous than most other teams at the company!
Well, IJ experience for Scala 3 is still noticeably worse than for Scala 2. We're still cross-compiling our work projects, waiting until Scala 3 support in Intellij is good enough to switch.
As other posters mentioned, a lot of it is about lacking critical mass in the first place. Making such a dramatic change is a high-risk thing, and Scala didn't have enough of a lead at all to justify it.
> The only bad thing was that it took quite long for Scala3 to become available leading to a lot of stagnation.
Unfortunately this isn't the only bad thing. The language overall is definitely a nicer language (though I complain about the whitespace change elsewhere). The tooling was broken for years, which actually stalled our team's migration. How could I advocate for moving to Scala 3, just to send everybody's editors and IDEs back to the stone age?
I'm not arguing that they built bad technology, I'm arguing that they ignored the reality: the value prop of moving to Scala 3 vs... moving to something else, at that point, isn't that compelling.
I remember being a big fan of Scala, and before Scala 3 it was looking to me that Kotlin was becoming a big competitor. Could that be, or do I have my timeline wrong?
It competes in some ways and not in others. It does a pretty good job of providing similar benefits as many Scala ecosystems, but providing approachability over purity.
Kotlin becoming The Official Android Language helps it quite a bit, though the future gets interesting if Google successfully abandons the JVM entirely to rid themselves of Oracle. I'm skeptical that Kotlin targeting multiple runtimes is a winning proposition, but it certainly seems to be doing a better job than Scala Native (also Rust is probably the better choice than Scala Native for that kind of code anyway).
> I'm skeptical that Kotlin targeting multiple runtimes is a winning proposition
Kotlin multiplatform being adopted by Google for huge projects like Google workspace makes it sound like it may actually be a winning proposition, if you ask me. Kotlin is replacing the more-than-a-decade old, battle tested, Java-to-ObjC translation at Google. I find that very impressive.
> also Rust is probably the better choice than Scala Native for that kind of code anyway
For sharing code between e.g. Android and iOS, Kotlin multiplatform seems to become the better solution. If you use Rust, you still have to call it from Swift and you just introduced a 3rd language.
I have always hated multiplatform frameworks, but Kotlin multiplatform is actually something that I find interesting (and flexible enough that you can choose where it makes sense to use it instead of committing to a whole framework).
> Kotlin multiplatform being adopted by Google for huge projects like Google workspace makes it sound like it may actually be a winning proposition, if you ask me. Kotlin is replacing the more-than-a-decade old, battle tested, Java-to-ObjC translation at Google. I find that very impressive.
When it comes to Google, I'll believe it when I see it. How's Fucshia?
> For sharing code between e.g. Android and iOS, Kotlin multiplatform seems to become the better solution. If you use Rust, you still have to call it from Swift and you just introduced a 3rd language.
I'm not positing Rust for this or any multiplatform thing, I was suggesting that Scala Native is eclipsed by Rust in its relatively narrow niche (and actually in addition to Rust, graal native-image).
