Mill: A fast JVM build tool for Java and Scala

Author here! Hope you take a look at the project and find it cool. There&#x27;s a lot of interesting stuff here. In particular, the Video linked on the landing page is a great intros from a Java developer point of view, and the following video is a great intro from a Build Tool Architect point of view:<p>* <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=UsXgCeU-ovI" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=UsXgCeU-ovI</a><p>While Mill is focusing on JVM for now, it is very extensible and I have a strawman demo of adding a Javascript toolchain in ~100 lines of code <a href="https:&#x2F;&#x2F;mill-build.org&#x2F;mill&#x2F;0.12.1&#x2F;extending&#x2F;new-language.html" rel="nofollow">https:&#x2F;&#x2F;mill-build.org&#x2F;mill&#x2F;0.12.1&#x2F;extending&#x2F;new-language.ht...</a><p>For those of you who want to learn more about the design principles and architecture of Mill, and what makes it unique, you should check out the page on <i>Design Principles</i> which has links to videos and blog posts where I elaborate on what exactly makes Mill so different from Maven, Gradle, SBT, Bazel, and so on:<p>* Mill Design Principles <a href="https:&#x2F;&#x2F;mill-build.org&#x2F;mill&#x2F;0.12.1&#x2F;depth&#x2F;design-principles.html" rel="nofollow">https:&#x2F;&#x2F;mill-build.org&#x2F;mill&#x2F;0.12.1&#x2F;depth&#x2F;design-principles.h...</a><p>I&#x27;ve mentioned this in a few places, but the comparisons with other build tools are best-effort. I have no doubt they can be made more accurate, and welcome feedback so I can go back and refine them. Please take them with a grain of salt<p>I&#x27;m also trying to get the community involved, so it&#x27;s not just me writing code and running the show. To that end, I have set up a bounty program, so pay out significant sums of money (500-2000USD a piece) for people who make non-trivial contributions. It&#x27;s already paid out about 10kUSD and has another 20kUSD on the table, so if anyone wants to get involved and make a little cash, feel free to take a shot at one of the bounties! <a href="https:&#x2F;&#x2F;github.com&#x2F;orgs&#x2F;com-lihaoyi&#x2F;discussions&#x2F;6">https:&#x2F;&#x2F;github.com&#x2F;orgs&#x2F;com-lihaoyi&#x2F;discussions&#x2F;6</a>

Just a note that the author Li Haoyi is a fantastic contributor to Scala community.<p>He has written multiple useful libraries. Out of many JSON libraries, his one was the most intuitive and practial.<p>His book is excellent too. I bought it when it came out. It is worthy of a plug: <a href="https:&#x2F;&#x2F;www.handsonscala.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.handsonscala.com&#x2F;</a><p>I miss working on Scala projects. Sadly I rarely see new ones these days.<p>Does IntelliJ plugin finally work on Scala 3? About 2 years ago it was half broken.

A build tool that is not only fast but configured in a type safe way sounds great. I really like this quote from the &quot;Why use scala&quot; part of the documentation:<p>&gt; Most developers using a build tool are not build tool experts, and have no desire to become build tool experts. They will forever be cargo-culting examples they find online, copy-pasting from other parts of the codebase, or blindly fumbling their customizations. It is in this context that Mill’s static typing really shines: what such &quot;perpetual beginners&quot; need most is help understanding&#x2F;navigating the build logic, and help checking their proposed changes for dumb mistakes. And there will be dumb mistakes, because most people are not and will never be build-tool experts or enthusiasts

I gave Mill a try earlier this year. My hope was to escape the nightmare that is Gradle, which I&#x27;ve been using for many years. Mill sounds great in theory (except for the Scala DSL). Unfortunately, I couldn&#x27;t get a basic Java build to work in half a day, even though I have (admittedly rusty) working knowledge of Scala. It was one obscure error after another. My conclusion was that Java support isn&#x27;t ready. There was also very little documentation on how to build Java.<p>In my opinion, using a GPL as the build language of a polyglot build tool is a dead end, both for technical&#x2F;usability reasons and because the ensuing language wars can&#x27;t be won. I&#x27;m looking forward to the day when a build tool embraces a modern config language such as CUE or Pkl.

Mill looks interesting, but, _from a Java development perspective_, it has the same fundamental challenge as Gradle (and most other build systems), which is that its config language _is something other than Java_. That means there&#x27;s a significant cognitive burden to understand and manage something that one hopes to not have to think about very often.<p>I find that the pain I experience with Gradle isn&#x27;t usually about how to do something clever or customized etc, but instead it&#x27;s when I haven&#x27;t thought about Gradle syntax in the last 3 months since everything has been silently working, but now I need to figure out some small thing, and that means I need to go re-learn basic Gradle stuff - whether it&#x27;s groovy, Kotlin, or some aspect of the build DSL - since my mind has unloaded everything about Gradle in the meantime.<p>Simplifying the semantic complexity of a general purpose build system will always help, but the most useful thing for me would be if the configuration for a Java build were to natively use the Java language directly.

The thing that’s great about maven is its declarative nature. You can declare goals and profiles for whatever you need the build system to do.<p>The main appeal that I can see from mill over maven is the power of dynamic programming over static xml files. Maybe good lsp&#x2F;ide support will make managing a build system like this bearable?

The comparision with Gradle is not up to date. There is stated that you would end up in an untyped mess of Groovy build files, but statically typed Kotlin files are the default for quite some time now in Gradle! <a href="https:&#x2F;&#x2F;mill-build.org&#x2F;mill&#x2F;0.12.1&#x2F;comparisons&#x2F;gradle.html" rel="nofollow">https:&#x2F;&#x2F;mill-build.org&#x2F;mill&#x2F;0.12.1&#x2F;comparisons&#x2F;gradle.html</a>

What tends to be complex about build requirements that necessitates special purpose tools? Golang seems to be doing fine with just go build and go test. What else are people doing with gradle&#x2F;maven that requires static typing, DAGs, plugins etc.?

It&#x27;s not clear to me how this is better than Gradle. And I hate Gradle.<p>At first glance, Mill looks like it has many of the pitfalls of Gradle: - Plugins: Creates the temptation to rely on plugins for everything, and suddenly you&#x27;re in plugin dependency hell with no idea how anything <i>actually</i> works. - Build scripts written in a DSL on top of a new language: Now I have to learn Scala and your DSL. I don&#x27;t want to do either! - Build scripts written in a language that can be used for code too: Versioning hell when the compiler for the build system needs to be a different version to the compiler for the actual project code. See: Gradle and Kotlin

Speed wins for dev tools.<p>I had worked out that math for “like pip but actually works” but few people were conscious that pip didn’t quite work reliably for large and complex projects — I didn’t think it was possible to sell it.<p>Uv won hearts and minds because it was uncompromisingly fast: people did not really care that it had a correct resolving algorithim or that is was really reliable because it is <i>not</i> written in Python and thus can’t trash it’s own dependencies (maybe a solvable problem in that the build tool can have its own virtualenv but isn’t it nice to for your package manager to be a binary that can’t get dependencies screwed up no matter how hard the users try?)

It&#x27;s great to see continuing innovation in the Java space!<p>One tool I&#x27;ve been using to speed up maven is mvnd, the maven daemon. It&#x27;s a drop in replacement for mvn with impressive speedups.<p><a href="https:&#x2F;&#x2F;github.com&#x2F;apache&#x2F;maven-mvnd">https:&#x2F;&#x2F;github.com&#x2F;apache&#x2F;maven-mvnd</a>

The last time I checked, sbt was much faster than mill for incremental builds. Mill has a faster cold startup time, but sbt uses classloader tricks to reuse jitted classes so that it doesn&#x27;t have to reload the scala standard library. When running tests continuously and rerunning on save, sbt was much faster than mill for equivalent projects. I haven&#x27;t tested in three years or so though. But I would encourage people to make a simple project in sbt and mill and run `sbt ~test` and compare it to `mill -w test`. In the past, I found that after a few iterations, sbt could respond to changes in a few hundred milliseconds while mill would take multiple seconds to retest the same code. That difference really adds up when you are iterating on a problem.<p>That said, I have come to believe that the jvm is a bad platform for a build tool. Everything that touches the jvm becomes bloated and slow, particularly for startup. I no longer write scala because of my frustration with the bloat (and scala adds its own bloat on top of the jvm).

I&#x27;ve used mill for some Scala projects in the past and I give it 5&#x2F;5.

Nice try, I&#x27;m still not going to write scala code.

Big fan of mill! (Coming from maven, Gradle and SBT) - the 1:1 mapping of build tasks to output files is the big one for me as it makes understanding other people&#x27;s builds so much easier going through it step by step

Why not compare it to bazel&#x2F;pants&#x2F;buck2 as well?<p>Mill seems to have taken some inspiration from those as well.

Sounds great!

Sorry to hijack this thread a bit, but I currently work at a Scala shop and have grown to like writing it. I worked at Clojure heavy place previously. This tool looks neat.<p>Has anyone at the senior level recently moved on from Scala to other languages recently? Any issue finding jobs or learning the new role?