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).
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.
I think the only way to make this constructive is if you could describe what you mean by “boilerplate”.
object, extends, def, Seq, etc. These things do not belong in the top-level description of the project.
And judging by your “false equivalence” statement, I’m not sure you actually read the thread I linked.
I just did. I am not at all convinced by lihaoyi’s reasoning. Maven already solved the “templating system” problem with POM inheritance. POMs are not functional programs. There is no need to pass values between different parts of the structure; simple variable substitution is usually adequate, and when it’s not, scripts and plugins fill the remaining gaps.
Cargo is factually a very basic tool, comparatively.
Maven isn’t, and although it has serious problems, none of them arise from the fact that its project description is not executable code. There is no need for that.
And there is a need for not-that: it takes a long time for IDEs to open sbt projects, and they frequently fail to do so at all. Maven and Cargo projects, meanwhile, open instantaneously and reliably.
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/
Yes, that’s the boilerplate I’m complaining about.
That belongs in a separate file, and the typical project shouldn’t need one.
That’s a false equivalence. Cargo is a full-fledged build system and handles multi-module projects.
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.
object,extends,def,Seq, etc. These things do not belong in the top-level description of the project.I just did. I am not at all convinced by lihaoyi’s reasoning. Maven already solved the “templating system” problem with POM inheritance. POMs are not functional programs. There is no need to pass values between different parts of the structure; simple variable substitution is usually adequate, and when it’s not, scripts and plugins fill the remaining gaps.
Maven isn’t, and although it has serious problems, none of them arise from the fact that its project description is not executable code. There is no need for that.
And there is a need for not-that: it takes a long time for IDEs to open sbt projects, and they frequently fail to do so at all. Maven and Cargo projects, meanwhile, open instantaneously and reliably.