Mill has way too much boilerplate. It makes the same critical mistake as sbt.
Go take a look at Cargo. That is the correct way to design a build system. Configuration is purely declarative, in a language (TOML) that doesn’t even allow imperative code. Custom build behavior, if any, goes in a separate script alongside the configuration file.
Also look at Maven, which tried and failed to do what Cargo has done successfully.
I rather disagree with the statement about mill’s perceived boilerplate, you build is composed/extended from classes and traits and the behavior is provided by overrides, OOP style. It’s nothing like sbt’s layered opaque architecture, yet you can do as many complex things as you need, programmatically, with the same scala language your project is written in.
As I said, you might not need that if your build is simple enough, and the more direct equivalent to cargo would be scala-cli. Going on a tangent here, Cargo is pretty basic and restrictive: scala build tools need to concern themselves with binary/ABI compatibility and cross targets compilation (to the JVM, JS, Native, WASM, …) all at once, whereas cargo only “cares” about source compatibility (no dynamic linking, no publishing in a compiled ABI stable form).
Here’s an interesting thread describing very well the problem space, and elaborating on the situation in rust/js (reply from mdedetrich): https://www.reddit.com/r/scala/comments/12jhud7/comment/jg2aecf/
you build is composed/extended from classes and traits and the behavior is provided by overrides, OOP style.
Yes, that’s the boilerplate I’m complaining about.
you can do as many complex things as you need, programmatically, with the same scala language your project is written in.
That belongs in a separate file, and the typical project shouldn’t need one.
the more direct equivalent to cargo would be scala-cli.
That’s a false equivalence. Cargo is a full-fledged build system and handles multi-module projects.
Cargo is pretty basic and restrictive: scala build tools need to concern themselves with binary/ABI compatibility and cross targets compilation (to the JVM, JS, Native, WASM, …) all at once, whereas cargo only “cares” about source compatibility (no dynamic linking, no publishing in a compiled ABI stable form).
That can be a problem, but it doesn’t justify Mill’s boilerplate.
I think the only way to make this constructive is if you could describe what you mean by “boilerplate”. My experience of writing and reading mill build files is that they are extremely succinct and convey their intent clearly.
And judging by your “false equivalence” statement, I’m not sure you actually read the thread I linked. Cargo is factually a very basic tool, comparatively.
