Kotlin has become a pretty big and complex language on its own so I'm not sure this is a good counterexample.

The fundamental issue is that fixing Scala 2 warts warranted an entirely new compiler, TASTy, revamped macros... There was no way around most of the migration pains that we've witnessed. And at least the standard library got frozen for 6+ years.

However I agree that the syntax is a textbook case of trying to fix what ain't broke. Scala 3's syntax improvements should have stuck to the new given/using keywords, quiet if/then/else, and no more overloaded underscore abuse.

Scala 2's syntax is mostly Java/C-style with a few peculiarities.

Scala 3's optionally allows indentation based, brace-less syntax. Much closer to the ML family or Python, depending on how you look at it. It does indeed look better, but brings its share of issues.[1] Worse, a lot of people in the community, whether they like it or not, think this was an unnecessary distraction on top of the challenges for the entire ecosystem (libraries, tooling, ...) after Scala 3.0 was released.

- [1] https://alexn.org/blog/2025/10/26/scala-3-no-indent/

That shouldn't be the case. There's an extension to VoWiFi to support SMS over IP. With 2G and 3G going away it's not like your carrier has a choice anyway.

And again, if there's nobody that can maintain sbt builds you're screwed anyway. This is precisely what I said earlier: bitrot and lack of upkeep are the real killer. Sbt is the least of your worries in such scenario. There's no way a team of inexperienced Scala developers can bootstrap a greenfield project unsupervised, unless they're committed to a slow and painful onramp period. Sbt is just one small variable here.

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.

If you work on internal libraries and apps, on a team with established practices, sbt shouldn't be a regular source of friction. It's really not that hard to define re-usable templates (you can even use Giter8!) for the typical multi-module build in a work setting. 99% of my projects either publish libraries to an internal Maven mirror, or packages apps with the native packager plugin, often OCI images nowadays. Sbt can be easily bootstrapped behind a Maven Central mirror entirely, you just need a single bash script. Sure the Maven and Gradle integrations in IntelliJ IDEA are more polished, but I'd pick sbt over these two without thinking, even for pure Java projects. Nowadays Mill is even better in many cases.

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.

My point is that the decline is multi-factorial, as usual.

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.

I'm not saying it played no role, but I think sbt's negative impact is overblown.

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 haven't defended Kotlin's approach in any way, I don't know why you want to put words in my mouth.

However if you don't see why Kotlin was well positioned, while Scala was not, then you clearly don't know much about either language.

Technical merit is subjective, but different design decisions can precisely be made to win politics or not, and JetBrains made the right ones, first to convince people internally (who knew about Scala, you know), then Google, as they were fairly well aligned.

Scala CLI should have happened 5 years before, but honestly sbt has improved a lot, the DX is mostly fine since the 1.0 release and it's maintained plugin compatibility for 8+ years.

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