Also too, bazel has this issue of googleability? like I feel like I can take any build issue I've run into in sbt and find the solution and an example by just searching, but with Bazel, anything outside of the happy path is a recipe for pain
Mill as a direct style build tool - https://news.ycombinator.com/item?id=43943792 - May 2025 (9 comments)
Why does Mill use Scala? - https://news.ycombinator.com/item?id=42997496 - Feb 2025 (75 comments)
Mill: A fast JVM build tool for Java and Scala - https://news.ycombinator.com/item?id=41967734 - Oct 2024 (162 comments)
What's So Special About the Mill Scala Build Tool - https://news.ycombinator.com/item?id=38877882 - Jan 2024 (1 comment)
Mill: A Build Tool Based on Pure Functional Programming - https://news.ycombinator.com/item?id=25925107 - Jan 2021 (1 comment)
Mill: Better Scala Builds - https://news.ycombinator.com/item?id=16775545 - April 2018 (16 comments)
In the last 5 years, I didn't need anything more than:
- resource plugin - compiler plugin - jar plugin (jars, test jars, javadoc jars) - surefire/failsafe - shade plugin for repackaging to avoid classpath hell - assemble plugin - license plugin
Most of the issues I had were with the shade/assemble/license plugins.
I consider myself a Maven power-user and like the tool compared to others (Gradle is too ant-like, resulting in non-standard builds, sbt is just a torture tool).
With time, I concluded that the simpler it is, the better.
I think I would prefer to use Mill than Maven (I haven't used Mill myself) ... going through the video tutorial, it's clear that it's also a very simple system without some of the ancient baggage of Maven (xml, too many plugins, etc).
I've been around for a while, I've used many different build systems for JVM based builds (Java, Hybrid Java/Clojure, Scala) and Maven is by far the simplest most solid.
The basic reason is it's commitment to being declarative.
I understand why programmers want imperative (we're programmers) but it's just the wrong choice for a build system.
I've worked on many OSS projects. I've never pulled a Maven-based project that didn't immediately build and immediately load into my IDE. However for imperative based build systems (Gradle, Ant, now Mill) it's almost inevitable that you won't be able to get the build to work right away or pulled into your IDE in a sensible way (as IDEs cannot read imperative statemetns).
I've created many many build with Maven with many many different demands (polygot codebase, weird deployment artifacts, weird testing runtime needs, etc etc) and Maven has never let me down. Yes, in some cases I've had to write my own plugin but it was good that I had to do that; it forced me to ensure I really needed to -- the Maven plugin ecosystem is already great and covers 90+% of use cases of builds.
I've met a lot of Maven naysayers and the disdain is almost always either some weird aversion to XML (such a trivial reason to choose a worser build system) and/or because the programmer never took the time to understand the rather simple Maven runtime semantics and architecture.
Build code in Mill is pretty declarative. You're using the word to mean "not 'pure, serialized data'".
> IDEs cannot read imperative statemetns
They can, however, run the code to dump the structure.
It's easy for code to embed pure data; on the flip side it's hard to encode behaviour in serialized data. More often than custom Maven plugins I see people just drop down to using shell.
In Java terms, if you have a big complicated Java repo that requires lots of steps to build, you should have a separate Java project in there just for building the main repo. That separate Java project should be built and run with maven, and that separate project can do all kinds of fancy things, but ultimately it will be generating maven projects or calling maven with special command line parameters or something like that.
I even put the logic for CI in my build project like this. It makes everything reproducible and debuggable. How cool is it to be able to put a breakpoint in your build script? How about stepping through your CI code? Things are way simpler this way.
I eschew frameworks in this custom build tool, because the build code should look conventional for whatever language it's written in.
You don't have to learn a separate language or some weird config.
This is kinda funny. Generating a profile that is meant to be visualized with a web browser's built-in profiler, not even an HTML file. I guess if it's already built and works well ¯\_(ツ)_/¯
I find SBT just has a lot of unnecessary abstractions and complexity. It's so opaque that I'm sure I'm leaving a lot of performance on the table with hidden antipatterns. Mill seems to solve that by being 'boring' (in a good way). Being able to trace what's happening in my IDE would be lovely - and something I don't have in SBT or Maven either.
Now that we also have fast running native CLI tooling, I think it's worth another look over SBT.
That said, Mill's performance claims sound interesting. If it really can cut build times by 3-6x, that's really amazing. I've wasted too much time in my life waiting for builds, especially on larger projects.
The Scala thing is a bit of a turn-off though. I get that you don't need to write Scala yourself, but now I'm dragging in the Scala ecosystem just to build my Java project? Feels heavy.
The IDE integration sounds nice in theory - being able to actually navigate and understand your build in IntelliJ would be pretty sweet.
Still not sure the switching costs are worth it unless you're really hitting Maven/Gradle pain points. But if I was starting a new project from scratch, might be worth a look.
These opinions are all valid, but only if they don't discount the validity of other strategies. There is no universal law of optimal build practices. There are cases where build performance is critical, and others where it's not. There are cases where configurability is important, and there are cases where it's not. Etc.
Personally, I love having a programmable build in plain Java, which is why I enjoy bld [1] these days. I'm probably the only person you'll ever meet who actually enjoyed using ant, so you're welcome to take my opinion with as much salt as you need to digest that.
I'm curious about those.
I think a lot of people expected this from Gradle because the idea of "build as programming" seemed like it would give that stop-the-train-let-me-on-already ability. I don't know that it really worked out that way. Maven is all about running devs over, but it's faster than Gradle, which tries to start a daemon just like SBT.
Anyhow... this bld thing looks interesting, thanks...
I strongly agree with this as a general principle in nearly all technical discussions.
But also, if the discussion starts with declaring something is better than everything else (as the title here), then there's really no salvaging it anymore.
Can someone from Astral fix Java too, please?
ivolimmen•3h ago
jpitz•3h ago
throwaway7783•3h ago
spullara•3h ago
ackfoobar•2h ago
If you have any complexity, programming against a good abstraction (Gradle is not good good, but decent) beats finding the magical incantation of configuration to get the tool to do what you want.
lenkite•2h ago
You can also download custom CLI tools and invoke them as part of a well-defined build lifecycle.
gf000•29m ago
At the very least, I would move to Gradle which does have proper knowledge of your build graph. But Mill is also a good choice and fills the same niche, with the added benefit that imperative-looking ordinary scala code will simply become a parallelizable, cacheable build graph.
switchbak•1h ago
Of course, sometimes the limitations are good: preventing you from doing "the wrong thing", or encouraging cacheability, etc. But as with any abstraction layer - getting a model that fits across so many disparate use cases can be very challenging.
henry700•3h ago
askonomm•2h ago
gf000•27m ago
imoverclocked•29m ago
Gradle groovy is extremely permissive (eg: you can access private class instance variables without even knowing that you are doing so)
Kotlin lacks that permissive quality in exchange for much easier introspection.
It’s often trivial to move from one to the other but those edge cases can find you in a codebase of any complexity.
chriswarbo•2h ago
Even better, Maven "POMs" are written in a common, standard format (XML); so we can transform and manipulate it using off-the-shelf tools, if we really want to. I've found this useful e.g. in pre-commit hooks (tidy the formatting, checking/linting, etc.); in Nix builds (e.g. removing the version number, so it doesn't affect the hash and avoids spurious rebuilds); etc. That was a nice bonus when I switched some projects from SBT to Maven (due to SBT being wildly unreproducible).