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.
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.
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!
> 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’ve always hated Java but Scala was super fun.
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?
The Enterprise ecosystem quickly withered away, and now only type level programming diehards remain.
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).
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...
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).
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).
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).
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.
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 find it disappointing: I tend to consider that Scala was an inspiration for Kotlin. Maybe Kotlin won by being simpler, and definitely because of the tooling and community: being backed by JetBrains and Google helps.
For a long time, the tooling was very limited with Scala, which must have slowed its adoption, right?
Gradle is worse on several dimensions, which didn't really hurt Kotlin's adoption, nor seems to fundamentally bother Android developers (ok, they have little choice here).
Maven is old and the DX isn't particularly stellar either. User friendly build tools are a relatively recent development in the programming language landscape. Hell, until uv, Python managed to be much worse than anything on the JVM.
I work at a company that used to do a lot in Scala, and I've seen the decline first hand. Lack of investment in basic upkeep and maintenance is the real killer. Bitrot hurts in Scala more than in Java. And sbt is not the biggest offender there.
I think a lot of posters make the mistake of saying "$otherLanguage has it worse." That's irrelevant! If otherLanguage is an incumbent, they can afford to have it worse. I don't think it's debatable that sbt harmed adoption in the first place and continued to represent a barrier to Scala's adoption for years, and it doesn't matter how good maven is or isn't.
The degree to which is certainly always going to be up for debate; as mentioned before, there are many factors, but sbt was not a nonfactor.
Scala needs some investment and commitment, you need a least one person who knows what they're doing: enforce a reasonable coding style, keep dependencies aligned and up to date, enable all the automated checks and linting, ...
Usually, when this is in place, then sbt is mostly a non-issue. You onboard a junior, they follow established practices, that includes the build. Sbt plugins are in fact a good way to standardize builds in a corporate setting.
Scala CLI was made for students and people who come from the outside. Sure, sbt is scary to them. But in the grand scheme of things, that's not what matters. Industry adoption doesn't really depend that much on the "zero to hello world" experience.
Case in point: several big Scala shops use Bazel. Bazel is 100x scarier than sbt and requires a bigger upfront investment.
And the fact Bazel rules exist for a language doesn't say much about its native toolchain really. Large scale polyglot codebases and especially monorepos don't play nice with common tooling. But anyway you're missing my point. Developer friendly toolchains are the exception, not the norm. There's some impact on industry adoption, but not a huge one all things considered. Otherwise nobody would have touched Python before 2024.
Your position presupposes quite a bit of "systems already in motion" to make the point that there isn't friction. Except... there is, and _somebody_ has to maintain your builds, and handle all those fun deprecations like when the integration test project gets removed and the syntax gets updated. These things aren't stable, untouched pieces of your services over time, and I want everybody on my team, not just some experienced Scala developer who has already performed the rituals required to understand and establish practices for sbt, to contribute.
And what about the onramp to Scala? I'm certainly not relying on a team of established practitioners to pave the way when I'm learning a new language. We're talking about a dying language, I think it's silly to dismiss this.
> But anyway you're missing my point. Developer friendly toolchains are the exception, not the norm. There's some impact on industry adoption, but not a huge one all things considered. Otherwise nobody would have touched Python before 2024.
And you continue to miss mine - incumbent languages can afford more friction than niche languages. Python or Java's ability to have mediocre dev experiences do not have much bearing on how impactful Scala's is (though frankly, Java is not really worse than Scala in my opinion, and trendwise I think we see sbt displaced by java tools or mill more than maven or gradle in the reverse, so the industry tends to agree).
For the sake of argument, imagine Scala had had the best build tool of the entire programming landscape in the past two decades. This would change nearly nothing to the current situation and Scala 3's adoption.
No need to read about how Kotlin is going to take over the world, while comparing it to samples written in Java 8, or the whole tooling infrastructure mess that needs to be changed, sorry improved, for each Google I/O, or stable Android Studio releases that crash on first use after upgrade, while "fixing" Gradle DSL changes.