I also work at a company that used to do a lot in Scala, and have seen the decline firsthand. Who's anecdata is better?

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.

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.

Bazel being used by some companies is not vindication that sbt wasn't a significant source of friction, just another arena where sbt was considered less fit for the job (whether one could argue sbt should have been able to do the job would certainly be context-dependent).

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.

I think we're simply going to have to agree to disagree.

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

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.