3 ms·

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 de

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.

blandflakes 10mo ago
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).
- hocuspocus 10mo ago
  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.

blandflakes 10mo ago

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

hocuspocus 10mo ago
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.