4 ms·

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 compa

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

blandflakes 10mo ago
I'm not advocating for Gradle either, but you already pointed out why the build tool being bad is relevant for Scala and not for Kotlin - Android developers have enough other reasons that they're going to use Kotlin, even though Gradle sucks. Scala developers... don't, and so just another straw stacked on a camel's back, so to speak.
- hocuspocus 10mo ago
  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.
  - blandflakes 10mo ago
    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.
    - hocuspocus 10mo ago
      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.
      - blandflakes 10mo ago
        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).
        hocuspocus 10mo ago
        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.
pjmlp 10mo ago
Gradle is only still around thanks to Android, thankfully I have moved away from Android projects. 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.

blandflakes 10mo ago

I'm not advocating for Gradle either, but you already pointed out why the build tool being bad is relevant for Scala and not for Kotlin - Android developers have enough other reasons that they're going to use Kotlin, even though Gradle sucks. Scala developers... don't, and so just another straw stacked on a camel's back, so to speak.

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

pjmlp 10mo ago

Gradle is only still around thanks to Android, thankfully I have moved away from Android projects. 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.