4 ms·

I saw a presentation recently on Mill[1] which looks extremely promising and looks poised to remove the giant Scala development headache of working with SBT. [

I saw a presentation recently on Mill[1] which looks extremely promising and looks poised to remove the giant Scala development headache of working with SBT. [1] https://github.com/lihaoyi/mill https://github.com/lihaoyi/mill

stephen 8y ago
sbt is terrible, and I have a lot of respect for Li as "the scala.js guy", but I'm slightly baffled that YABT (yet another build tool) was really necessary vs. just making the existing (say) gradle experience super-polished. Granted, it's probably more fun to start from scratch :-), just seems more realistic for long-term adoption/maintainability to leverage existing tools.
- lmm 8y ago
  I've never understood what SBT was supposed to solve in the first place. A Maven plugin that supports cross-building, which we're finally now getting with Scalor, seems like what the language actually needed.
  - tomerbd 8y ago
    https://www.acronymfinder.com/Sucks-Big-Time-(SBT).html https://www.acronymfinder.com/Sucks-Big-Time-(SBT).html
- lomnakkus 8y ago
  The models of SBT/Gradle/Maven are broken, or at least, that's the premise for writing these build tools. The model of Mill, Bazel, Buck, Pants are fundamentally different in very important ways which allow e.g. using a shared build cache across all the developers in a team (or even all the developers in a whole company if one takes the monorepo approach for absolutely everything). This is not something that can be retrofitted into, say, SBT or Gradle.
  - stephen 8y ago
    Gradle does have a build cache, which can be local or remote: https://docs.gradle.org/current/userguide/build_cache.html https://docs.gradle.org/current/userguide/build_cache.html It is a newer feature, so that might be why you're unaware of it. Also, I get that the models of Bazel/Buck/Pants are fundamentally different, because they are inherently cross-language / "sit on top of other compilers" systems. And are best for mono repos. But Mill doesn't fit in that camp AFAICT.
    - lomnakkus 8y ago
      Ah, right I wasn't aware of that. Still, AFAICT Gradle isn't nearly as 'ambitious' in tackling the hard problem of hermetic/reproducible builds as e.g. Bazel, so who knows how reliable that build cache actually is. You may well be right about Mill, but it's probably too early to tell exactly where it'll land in the design space. (Btw, I think it's entirely right to be wary of yet-another-build-system, especially when it doesn't seem to do anything that other systems don't already do.)

stephen 8y ago

sbt is terrible, and I have a lot of respect for Li as "the scala.js guy", but I'm slightly baffled that YABT (yet another build tool) was really necessary vs. just making the existing (say) gradle experience super-polished. Granted, it's probably more fun to start from scratch :-), just seems more realistic for long-term adoption/maintainability to leverage existing tools.

lmm 8y ago
I've never understood what SBT was supposed to solve in the first place. A Maven plugin that supports cross-building, which we're finally now getting with Scalor, seems like what the language actually needed.
- tomerbd 8y ago
  https://www.acronymfinder.com/Sucks-Big-Time-(SBT).html https://www.acronymfinder.com/Sucks-Big-Time-(SBT).html
lomnakkus 8y ago
The models of SBT/Gradle/Maven are broken, or at least, that's the premise for writing these build tools. The model of Mill, Bazel, Buck, Pants are fundamentally different in very important ways which allow e.g. using a shared build cache across all the developers in a team (or even all the developers in a whole company if one takes the monorepo approach for absolutely everything). This is not something that can be retrofitted into, say, SBT or Gradle.
- stephen 8y ago
  Gradle does have a build cache, which can be local or remote: https://docs.gradle.org/current/userguide/build_cache.html https://docs.gradle.org/current/userguide/build_cache.html It is a newer feature, so that might be why you're unaware of it. Also, I get that the models of Bazel/Buck/Pants are fundamentally different, because they are inherently cross-language / "sit on top of other compilers" systems. And are best for mono repos. But Mill doesn't fit in that camp AFAICT.
  - lomnakkus 8y ago
    Ah, right I wasn't aware of that. Still, AFAICT Gradle isn't nearly as 'ambitious' in tackling the hard problem of hermetic/reproducible builds as e.g. Bazel, so who knows how reliable that build cache actually is. You may well be right about Mill, but it's probably too early to tell exactly where it'll land in the design space. (Btw, I think it's entirely right to be wary of yet-another-build-system, especially when it doesn't seem to do anything that other systems don't already do.)