Note that while Mill's first target is Scala builds (as an alternative to SBT) there isn't much reason why Mill shouldn't be usable for other JVM/non-JVM languages too.
Mill's core is basically a dependency-graph-based caching task-runner, similar to Bazel, which happens to be written in Scala (rather than Skylark). Scala+Java support is just a bunch of helper methods built on top of that.
It should be pretty trivial to make it work for Java-only projects (https://github.com/lihaoyi/mill/issues/145) or write the necessary helper methods to make it work for other languages or platforms.
Generally before adopting a language for a new project, (for me) it would need to have things like:
- good build tool including dependency management
- reasonably fast compiler
- decent standard library
- pretty good IDE support
- clear policy about backwards compatibility
- good REPL
- good documentation (including contribution policy and license)
But there are surprisingly few language ecosystems that have all these fundamental features, even after many years (decades) of development! And many others seem to not appreciate how important they are, leading to years of tepid adoption or only niche usage at best.
Does anyone have any code examples / GitHub repos of Spark projects that are setup with Mill? I've been fighting with build.sbt files for a couple of years and am ready to try out some alternatives.
One of the barriers to switching to this, for my project, is the sbt-native-packager plugin and the way we use it to build debian packages. This plugin is one of the best things about sbt.
I've developed a grudging respect for SBT. It's a petty remarkable project and I don't want to disrespect the people who work in it in any way.
That said, I've been writing Scala for years now and still struggle to modify my builds. And for my team, SBT is a major barrier to entry for people new to Scala.
Once I feel like I can port my build over, I'm going to give Mill a try.
I have some SBT-specific stuff on some projects that is going to slow me down in trying this (namely multiple sbt-web plugins and Play plugin). However, I might have some runway to contribute some ports of these things.
Kotlin is a better Java, or simpler Scala. Simpler can be better for plenty of teams, especially for those coming from Java. But I'll not be switching any time soon.
After 10years of Scala development, SBT is still the largest pain. Compile speed, picking up changes takes many seconds, arcane syntax, magic error messages, fragile configuration files.
Will try mill, I wonder why no other build tools for scala showed up, with SBT being such a pain for many people.
We use pants internally. (https://pantsbuild.org) Comes from Twitter, and - if I understand correctly - based on many of the ideas from Bazel. It’s actively maintained and updated.
Mill's core is basically a dependency-graph-based caching task-runner, similar to Bazel, which happens to be written in Scala (rather than Skylark). Scala+Java support is just a bunch of helper methods built on top of that.
It should be pretty trivial to make it work for Java-only projects (https://github.com/lihaoyi/mill/issues/145) or write the necessary helper methods to make it work for other languages or platforms.