12 ms·

Mill: A fast JVM build tool for Java and Scala

185 points by 0x54MUR41 2y ago

juangbet 2y ago
[flagged]
spuz 2y ago
A build tool that is not only fast but configured in a type safe way sounds great. I really like this quote from the "Why use scala" part of the documentation: > 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 "perpetual beginners" need most is help understanding/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
potamic 2y ago
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/maven that requires static typing, DAGs, plugins etc.?
- iamcalledrob 2y ago
  I'm working on a project that encompasses both JVM (Gradle, Kotlin) and Golang. My hot take: JVM build tools, especially Gradle, are a soup of unnecessary complexity, and people working in that ecosystem have Stockholm Syndrome. In Golang, I spend about 99% of my time dealing with code. In JVM land, I'm spending 30% just dealing with the build system. It's actually insane, and the community at large thinks this is normal. The amount of time it takes to publish a multi-platform Kotlin library for the first time can be measured in days. I published my first Golang library in minutes, by comparison.
  - threeseed 2y ago
    > the community at large thinks this is normal Half are ignorant. Other half are like me and just stuck with no options. But the tooling ecosystem on the JVM truly is horrific.
    - iamcalledrob 2y ago
      I think there are a lot of "JVM Lifers" who are so deep in the ecosystem they are unaware how much better things can be. Anecdote: I wanted to publish a ~100LoC multiplatform Kotlin library -- just some bindings. I publish these sorts of things for Go with just a "git push". Steps were: 1. Spend a few hours trying to understand Maven Central/Sonotype, register and get "verified". They're in the middle of some kind of transition so everything is deprecated or unstable. 2. Figure out signing, because of course published packages must be signed. Now I have a secret to keep track of too, great. 3. Discover that there is no stable Gradle plugin for publishing to the "new" Maven Central, it's coming soon... Choose one of the handful of community plugins with a handful of stars on GitHub. 4. Spend a few hours troubleshooting a "Gradle build failed to end" error, which ended up being due to signing not finding a signing key. 3rd party plugin didn't handle errors properly, and a bug in Gradle meant that my secret wasn't picked up from local.properties. 4. Eventually discover that because Kotlin Multiplatform can't be cross-compiled, there is no way to actually publish a multiplatform library without spinning up a bunch of CI runners. And you can't just publish code -- JVM packages have to contain compiled artifacts. 5. Realise this now involves maintaining GitHub Actions and Gradle, which is an ongoing cost. 6. Give up. The harm that this kind of complexity must be causing to the ecosystem is immeasurable.
      - iainmerrick 2y ago
        I’d just like to add, NPM gets a lot of flak (mostly deservedly) but it too is still vastly easier than anything in the JVM ecosystem. Even with all the headaches around modules versus CJS, and JS versus TypeScript, NPM is a lot easier than Gradle. Notably, you have a choice of alternate tools (eg pnpm, yarn, bun) that interoperate pretty well. I guess my point is, Gradle and Maven are specifically and outstandingly bad.
- rykad 2y ago
  To be blunt, nothing. The issue is that most people in jvm land are on a closed bubble and haven't seen anything else. This is true for build systems as is for non OO design for example. Most simply don't know better and the rest of us are simply stuck. Ant and then Maven started simple enough but people always find a way to justify adding more stuff. Gradle already started complex enough and they keep adding more stuff...
  - cryptos 2y ago
    You have to keep in mind that Gradle Inc. earns money by providing consulting for complex builds. An easy build tool would destroy this business model ;-)
    - mrudolph22 2y ago
      They transitioned to a product company 5+ years ago. https://gradle.com https://gradle.com Gradle's complexity comes from at least two places: 1. The original vision of solving complex multi-technology/language Enterprise builds. 2. Poor early design decisions that they never recovered from.
  - kaba0 2y ago
    To be blunt, if anything it might be you who live in a closed bubble. Builds that require ad-hoc functionality is the default. It’s extremely rare that everything fits nicely into “cargo build” or other single language build tools’ model. And while these often have escape hatches, at that point you have to write imperative code with no caching and parallelization that is literally the job of a build tool.
    - rykad 2y ago
      I've been doing jvm apps for almost 20yrs... What builds need to do and what people made the builds do are completely different things. I don't remember a single project I was involved in that could not had had a simpler build...
      - 2y ago
- dikei 2y ago
  In JVM world, the de factor equivalent to `go build` and `go test` are `mvn compile` and `mvn test`, which works 99% percent of the time. Other build tools and plugins just compete/fill in for: * improved build speed / test speed: using background daemon to reduce strtup speed, intelligent caching / task reordering to avoid redoing, etc.. * extra functionalities like code generation, publishing or deployments. As code generation is really big in JVM world, and there are many ways to deploy an application: jar + libs in a zip file, uber jars, container image, etc...
  - dcminter 2y ago
    Curmudgeon here: this was true for a relatively brief period of time. Nowadays I'd say that gradle has (inexplicably to me) taken the lead - and everyone adds custom crap to their gradle build making them far less predictable than maven builds used to be. I guess it's better than the nightmare over in the front-enders' world...
    - switchbak 2y ago
      I rarely see Maven files in non-trivial projects that are anything but a confusing mess of XML. Granted, the constrained abilities do tend to keep folks from writing one-off snowflake build customizations, which is nice. But it still leave a hell of a lot to be desired. It was however, leagues ahead of Ant, which wasn't a high bar.
      - dcminter 2y ago
        I saw a lot of that too - I just see more and worse with gradle. Maven gave us two things; good dependency management and convention driven builds (removing the horrible scripted build stuff in Ant). Gradle from my point of view took the second one away again and it feels like it was just because people didn't like XML and couldn't be bothered to learn how Maven's build lifecycle actually worked! Like I say, I'm a curmudgeon...
  - pkolaczk 2y ago
    My typical mvn session after a month of not touching maven: % mvn [ERROR] No goals have been specified for this build. Uh. % mvn build [ERROR] Unknown lifecycle phase "build". Uh, nope, that wasn't it.... % mvn compile BUILD SUCCESS Now trying to run the app... Error: app jar not found. Reading the README.md. Aha! So I need to install it! % mvn install 16:59:35,075 [INFO] Building <blahblahblah> [1/32] ... 16:59:38,483 [INFO] ------------------------------------------------------- 16:59:38,483 [INFO] T E S T S 16:59:38,483 [INFO] ------------------------------------------------------- ^C // me searching on google how to not run tests % mvn install -DskipTests=true // now good... Ok, let's run some tests. The FlakyTest broke again in CI. Let me run it locally: % mvn test FlakyTest 17:02:19,481 [ERROR] Unknown lifecycle phase "FlakyTest". Aaargh, ok, googling it again: % mvn test -Dtest=FlakyTest 17:03:16,102 [ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:3.3.0:test (default-test) on project blah blah: No tests matching pattern "FlakyTest" were executed! (Set -Dsurefire.failIfNoSpecifiedTests=false to ignore this error.) The original idea behind maven is nice. But the defaults are so bad, that the whole experience of convention over configuration has been ruined. Cargo and go build systems took the original maven philosophy and implemented them right, with good UX. Gradle, SBT and friends took a step back to the times before maven, and went fully the Ant way, doubling down on "configuration over convention". Where "configuration" is actually "programming in a DSL on top of another language on top of Java".
- mike_hearn 2y ago
  Build tools sit in an unhappy corner of the design space where they provide features not found in the core of regular programming languages, and which are so generally useful that there's a temptation to make them very abstract, but then they often lack some of the features that let regular programs scale well. The key feature that justifies their existence is parallel and incremental execution of DAGs of world-mutating tasks. This is an awkward fit with most programming languages, hence the prevalence of DSLs. But people don't want their build system to become a general purpose programming language, because they don't want to think about build systems at all and because programmers don't buy programming languages anymore, so, this causes a big design tension between generality (people want to use build systems to automate many things) and deliberately limiting the expressive power to try and constrain the design space and thus tooling investment required. Java is in an awkward place because the JDK was born in the 90s on UNIX, by people who thought make is a sufficiently good solution. You still see remnants of this belief in the official Java tutorials, in JEPs, and in the fact that OpenJDK itself is compiled using an autotools based build system! (fortunately it's one of the nice make based build systems out there). The problem with make is twofold: 1. It assumes a CLI that's both powerful and standardized provided by the host OS. Windows violates this assumption but Java is meant to be portable to Windows. 2. "Plugins" are CLI tools or scripts and so make implicitly assumes that subprocess creation is cheap. But process creation on Windows is expensive, and starting up JVM programs is also expensive due to the JIT compiling. Therefore make just doesn't work well in the JVM ecosystem. At the same time, the Java project wasn't providing any competing solution, so the wider open source community was left to fill in the gaps. These days language developers provide build tooling out of the box as part of the base toolset along with the compiler, but Java still doesn't. So - you ask, what are people doing with Gradle/Maven that requires all those features. The answer is: everything! Gradle builds frequently orchestrate dozens of different tools as part of a build pipeline, build documentation websites, do upload and deployment, download and manage dependencies, run security scanners and license compliance checkers, analyze dependency graphs, modify compiler behaviors, and so on. Additionally Gradle isn't specific to Java, or even JVM apps. It can also be used to compile C/C++ programs, run native code compilers like Kotlin/Native, and it abstracts the underlying platform so Gradle builds aren't tied to UNIX. That's why it's so complicated.
  - 2y ago
- lihaoyi 2y ago
  Author here! `go build` and `go test` do work, at limited scale and complexity. In Scala there's Scala-CLI which is excellent. If they work for you, you probably aren't the target market for these build tools. Once you start layering on bash scripts, layering on make, layering on Python scripts, layering on manual steps written down in a readme.md somewhere, that's the time when you should consider a proper build tool. And if that has never happened to you in your career, count your blessings :) Why not just write some boring, pure code to handle the build? Why not write my build system in vanilla LYAH Haskell? It turns out that builds do have some specific requirements that most programs do not need to care about: caching, parallelization, introspection, and so on. Check out the following blog/talk for more details: * Blog Post: Build Tools as Pure Functional Programs https://www.lihaoyi.com/post/BuildToolsasPureFunctionalPrograms.html https://www.lihaoyi.com/post/BuildToolsasPureFunctionalProgr... * Video: Mill: a Build Tool based on Pure Functional Programming https://www.youtube.com/watch?v=j6uThGxx-18&list=PLBqWQH1MiwBSThMSFV4k4dGTZkS0mfbxo&index=16&t=27s https://www.youtube.com/watch?v=j6uThGxx-18&list=PLBqWQH1Miw... Thus "naively" building your project "directly with code" ends up not working, so you do need some additional support. While most build tools end up constructing a complete bespoke programming environment from scratch, Mill tries to leverage the Scala language and JVM as much as possible, so you can re-use all your expertise and tooling (e.g. IntelliJ, VSCode, Maven Central, etc.) almost verbatim while getting all the necessary build-tool stuff (parallelism, caching, introspection) for free. Check out those two links if you want to learn more!
  - potamic 2y ago
    Thanks, the post actually answers my question on build requirements. It's a very good write up overall! If your USP is to solve those layering cases, then why not target other ecosystems like golang/rust as well? Your design philosophy certainly seems to be language agnostic. By calling yourself a build tool for Java and Scala, it gives an impression that this is solving problems specific to those environments, and your adoption also indicates as such. Is it that these communities do not like to adopt such tools or is there something about the JVM ecosystem that tends towards having complex build requirements?
    - 2y ago
- kaba0 2y ago
  There are quite a few cases: the moment you touch another language, resources that require a compile-step (e.g. xml schemas to code dtos, protonbuf, all that kind of stuff), sometimes even the code itself requires generation.
- zem 2y ago
  I recommend the "build systems a la carte" paper for a good overview of the various problems build systems address
- cyberax 2y ago
  Try to build a Go project that uses Cgo and non-trivial C/C++ libraries. Throw in cross-compilation for more fun. You'll end up with an external build system that invokes Go build as one of the steps. Go projects normally just tend to be self-contained server-like software that doesn't need a lot of external libraries. But once you step away from that, you're on your own. I guess my problem with Gradle is that app building should be way simpler than it is. Apps are not something niche anymore, but the tooling is still similar to the embedded software for microcontrollers.
iamcalledrob 2y ago
It's not clear to me how this is better than Gradle. And I hate Gradle. 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're in plugin dependency hell with no idea how anything actually works. - Build scripts written in a DSL on top of a new language: Now I have to learn Scala and your DSL. I don'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
- fabioz 2y ago
  The first advantage the homepage lists is: > Mill can build the same Java codebase 5-10x faster than Maven, or 2-4x faster than Gradle Speed per se can be a good selling point (having to wait for slow builds is really annoying). I can't really comment on anything else though as I just stumbled upon it here in HN ;)
  - iainmerrick 2y ago
    The goal should be more like 50x faster than Gradle. Gradle is ludicrously slow (at least in every single Gradle project I’ve had to work with).
    - kaba0 2y ago
      First invocation may be. Subsequent builds are very fast, unless someone decided to write random bullshit into the build scripts that execute at config time, making the config process impure.
      - iainmerrick 2y ago
        I’m mostly thinking of Android projects. If I have time I’ll try some speed tests with a new basic project. But I don’t think I’ve even once done something in Android Studio and thought “huh, that was surprisingly fast”. Maybe some of the hot reloading stuff is okay (when it actually works).
juangbet 2y ago
[flagged]
cryptos 2y ago
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! https://mill-build.org/mill/0.12.1/comparisons/gradle.html https://mill-build.org/mill/0.12.1/comparisons/gradle.html
- lihaoyi 2y ago
  Author here. Unfortunately this is because my own experience with Gradle is not up to date; I've only lived in the Gradle Groovy world! If anyone is interested in helping out, I have a 1500USD bounty on porting a gradle.kts build to Mill, so we can do a fair up-to-date comparison https://github.com/com-lihaoyi/mill/issues/3670 https://github.com/com-lihaoyi/mill/issues/3670
  - mdaniel 2y ago
    I believe you have influence over the syntax highlighting on GitHub of .mill files by informing it they're actually Scala, which would make reading those files much nicer IMHO: https://github.com/github-linguist/linguist/blob/v8.0.1/docs/overrides.md#using-gitattributes https://github.com/github-linguist/linguist/blob/v8.0.1/docs... Or, I believe you can submit a PR to linguist to make it globally registered: https://github.com/github-linguist/linguist/blob/v8.0.1/CONTRIBUTING.md#adding-an-extension-to-a-language https://github.com/github-linguist/linguist/blob/v8.0.1/CONT...
  - imtringued 2y ago
    You can maintain your competitive advantage over gradle by not constantly breaking backwards compatiblity, by the way.
- brabel 2y ago
  I never got why people thought Kotlin would help Gradle. It absolutely doesn't. Groovy was never the problem (Groovy has types, always had, you could use them if you wanted). Think about it: what do you do with a build tool? You write a little recipe, then you run it. Does that remind something? Yes, it reminds scripts, like bash scripts you run all the time in your terminal. And why are scripts almost universally written without types... and no typed alternative, of which there are many, has caught on? Because if you're just going to modify a script and immediately run it, while keeping it short enough so you can know what it does without reading a book, how does adding types help you? Quite to the contrary, scripts (including build scripts) should be small, and having types all over the place make it far more verbose than it should be, likely pushing it out of your comfortable local memory in your brain, at which point you need something akin to a "real" programming language and a compiled program, not a script. Larger programs benefit from types because you don't just run the program, make changes, and run them again, like you do with scripts. You write them, test them, compile them, package them and finally you distribute them to your users who hopefully only need to configure them, not modify their internals. If your build is that complex, that's exactly what you should be doing instead of trying to shoehorn types into your scripts and expecting them to look like real programs. Also, the Kotlin DSL just doesn't assist in the most problematic aspect of Gradle: its total lack of discoverability. Try doing something on your Kotlin Gradle file using a plugin you're not familiar with (which is all of them for most of us). It's completely impossible unless you know the DSL of the plugin, just like it was the case with Groovy... Once you know the DSL, it's fairly easy, but even in Groovy you will get auto-completion once you've got to the DSL "entry point", no need for Kotlin. I've been saying this since before they introduced the Kotlin DSL, and now i feel completely vindicated. I've never met anyone who told me "Gradle is so much easier now with Kotlin". But it did mess up plugins I wrote in Kotlin as now Gradle has a dependency on a very particular version of the Kotlin compiler, and God help you if your plugin was written with a different version in mind.
jiehong 2y ago
Why not compare it to bazel/pants/buck2 as well? Mill seems to have taken some inspiration from those as well.
- lihaoyi 2y ago
  Author here. It does! I started working on Mill when I started learning Bazel, during my first months at Databricks. There's a lot of cross-pollination of ideas there, from my 7 years adopting and maintaining the Bazel build at Databricks, but I haven't had time to do a proper head-to-head comparison. Hopefully someone else can though!
  - wocram 2y ago
    What drove you away from Bazel? I would expect anyone considering migrating away from a "legacy" tool like maven would consider a "modern" tool like Bazel first.
    - lihaoyi 2y ago
      Bazel is a rats nest of complexity. In my experience it does what it does very well once set up, but setting it up is tremendously complicated, much of it IMO incidental complexity. Rolling out Bazel at my prior employer tool about one person decade of engineering time. I've talked to other companies that tried to roll it out and failed. Bazel is hard And Bazel is not really getting any easier! Like most projects, it is getting more complex over the years as features acrete. I think there is space for a tool like Mill for less sophisticated users who can't afford to spend a person-decade rolling out their build tool
      - robert-brown 2y ago
        There's a big difference between the complexity of setting up Bazel and the experience of using Bazel at a company where Bazel has been set up for you. As a user I love Bazel. When working with Java, I use the java_binary and java_library rules. When coding in Go, there's nothing new to learn regarding the build, just use go_binary and go_library instead. Everything is repeatable, builds and tests are cached, it's easy to query the build dependency tree, etc. A few startups are offering "Bazel build/test as a service." It's one way to eliminate the work involved in setting up Bazel for an organization.
lihaoyi 2y ago
Author here! Hope you take a look at the project and find it cool. There'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: * https://www.youtube.com/watch?v=UsXgCeU-ovI https://www.youtube.com/watch?v=UsXgCeU-ovI 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 https://mill-build.org/mill/0.12.1/extending/new-language.html https://mill-build.org/mill/0.12.1/extending/new-language.ht... 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 Design Principles 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: * Mill Design Principles https://mill-build.org/mill/0.12.1/depth/design-principles.html https://mill-build.org/mill/0.12.1/depth/design-principles.h... I'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 I'm also trying to get the community involved, so it'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'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! https://github.com/orgs/com-lihaoyi/discussions/6 https://github.com/orgs/com-lihaoyi/discussions/6
- philipwhiuk 2y ago
  The current version is 0.12.1. What's required for v1.0?
  - lihaoyi 2y ago
    Traditionally I've labelled my OSS projects 1.0 when they've stabilized and the rate of change has greatly reduced. Right now Mill is not there yet, but maybe if at end-2025 we realize no breaking changes have been needed since end-2024, we can call it 1.0
sireat 2y ago
Just a note that the author Li Haoyi is a fantastic contributor to Scala community. He has written multiple useful libraries. Out of many JSON libraries, his one was the most intuitive and practial. His book is excellent too. I bought it when it came out. It is worthy of a plug: https://www.handsonscala.com/ https://www.handsonscala.com/ I miss working on Scala projects. Sadly I rarely see new ones these days. Does IntelliJ plugin finally work on Scala 3? About 2 years ago it was half broken.
k3vinw 2y ago
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. The main appeal that I can see from mill over maven is the power of dynamic programming over static xml files. Maybe good lsp/ide support will make managing a build system like this bearable?
- lihaoyi 2y ago
  Yes, IDE support in Mill is key. Without IntelliJ or VSCode, Mill would not be nearly as pleasant to use as it is today. Mill and Maven both let you declare goals for what you want to do. One does it in XML and one does it in typechecked code. While XML does work, doing things in code with typechecking and full IDE support turns out to be pretty nice as well!
msl09 2y ago
Nice try, I'm still not going to write scala code.
- galdosdi 2y ago
  Build times always were my biggest Scala complaint. Arguably code base specific, as I suspect it had a lot to do with all the macros and type level metaprogramming, but, if that kind of thing is possible and customary, an average working programmer who doesn't control the codebase they show up to is going to end up stuck dealing with it. It's a lot easier to build a language that works great, but only in the hands of a single skilled careful owner, than a language that stands up to the abuse of many careless temporary users, and still gets from point A to point B reliably. Like the difference between a sportscar and a rental company or police fleet sedan. Scala was a porsche, but most of us need camrys.
whoodle 2y ago
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. Has anyone at the senior level recently moved on from Scala to other languages recently? Any issue finding jobs or learning the new role?
- deleted 2y ago
  [deleted]
pnathan 2y ago
I've used mill for some Scala projects in the past and I give it 5/5.
carrotsalad 2y ago
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's a significant cognitive burden to understand and manage something that one hopes to not have to think about very often. I find that the pain I experience with Gradle isn't usually about how to do something clever or customized etc, but instead it's when I haven'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's groovy, Kotlin, or some aspect of the build DSL - since my mind has unloaded everything about Gradle in the meantime. 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.
- beeboobaa3 2y ago
  My problem with gradle is that its configuration language is a programming language. Sounds amazing in practice. And it is. Until you need to fix a 3 year old build that has some insane wizardry going on.
  - mdaniel 2y ago
    > Until you need to fix a 3 year old build that has some insane wizardry going on. My experience with Gradle is that it's the "3 year old build" that is almost certainly a death knell more than the insane wizardry part. My experience: git clone .../ancient-codebase.git cd ancient-codebase ./gradlew # <-- oh, the wrapper, so it will download the version it wants, hazzah! for _ in $(seq 1 infinity); do echo gradle vomit you have to sift through; done echo 'BUILD FAILED' >&2 exit 1 Contrast that with https://github.com/apache/maven-app-engine https://github.com/apache/maven-app-engine (just to pick on something sorted by earliest push date, some 10 years ago): $ git clone https://github.com/apache/maven-app-engine.git $ cd maven-app-engine $ mvn -B compile [INFO] ------------------------------------------------------------- [ERROR] COMPILATION ERROR : [INFO] ------------------------------------------------------------- [ERROR] error: Source option 6 is no longer supported. Use 8 or later. [ERROR] error: Target option 6 is no longer supported. Use 8 or later. [INFO] 2 errors $ echo "Java gonna Java" $ git grep -n source.*6 pom.xml:133: <source>1.6</source> $ sed -i.bak -e 's/1.6/1.8/g' pom.xml $ mvn -B compile [INFO] BUILD SUCCESS
mrudolph22 2y ago
I gave Mill a try earlier this year. My hope was to escape the nightmare that is Gradle, which I've been using for many years. Mill sounds great in theory (except for the Scala DSL). Unfortunately, I couldn'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't ready. There was also very little documentation on how to build Java. In my opinion, using a GPL as the build language of a polyglot build tool is a dead end, both for technical/usability reasons and because the ensuing language wars can't be won. I'm looking forward to the day when a build tool embraces a modern config language such as CUE or Pkl.
- lihaoyi 2y ago
  Depending on when you tried, it could be worth trying again: support for Java has improved greatly in the last few months, as have the documentation. Come by our discord channel if you get stuck and i can help unblock you
  - mrudolph22 2y ago
    Thanks for the offer! I’ll give Mill another shot the next time Gradle drives me crazy. :-)
- zcw100 2y ago
  I've had the same gripe about having to keep up with a second language just for the build tool for a while. Try taking a look at JeKa https://jeka.dev/ https://jeka.dev/
PaulHoule 2y ago
Speed wins for dev tools. 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. 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 not 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?)
thefaux 2y ago
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'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'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. 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).
- weego 2y ago
  sbt is one of the worst engineering mistakes I've ever witnessed. It was a constant source of esoteric ergonomics and frustration for no clear reason other than being the pet project of someone who really loved implicits.
- lihaoyi 2y ago
  The test thing is just a matter of defaults, in Mill subprocess testing is the default and in-process testing opt-in via .testLocal. I also believed that a lot of existing JVM tooling is bloated and slow, so we are in agreement! Mill tries to be different, so do give it a chance if you can. There is life beyond Maven, Gradle, and SBT
TeaVMFan 2y ago
It's great to see continuing innovation in the Java space! One tool I've been using to speed up maven is mvnd, the maven daemon. It's a drop in replacement for mvn with impressive speedups. https://github.com/apache/maven-mvnd https://github.com/apache/maven-mvnd
- speed_spread 2y ago
  I'm not sure I like the daemon approach. But the cache extension provided me fantastic gains: https://github.com/apache/maven-build-cache-extension https://github.com/apache/maven-build-cache-extension
  - lihaoyi 2y ago
    Mill uses the same daemon design as Gradle and mvnd. You do hit edge cases occasionally, but overall it works great
Raydat 2y ago
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's builds so much easier going through it step by step
khana 2y ago
[dead]
BillLucky 2y ago
Sounds great!

185 points by 0x54MUR41 2y ago

[flagged]

spuz 2y ago

A build tool that is not only fast but configured in a type safe way sounds great. I really like this quote from the "Why use scala" part of the documentation: > 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 "perpetual beginners" need most is help understanding/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

potamic 2y ago

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/maven that requires static typing, DAGs, plugins etc.?

iamcalledrob 2y ago
I'm working on a project that encompasses both JVM (Gradle, Kotlin) and Golang. My hot take: JVM build tools, especially Gradle, are a soup of unnecessary complexity, and people working in that ecosystem have Stockholm Syndrome. In Golang, I spend about 99% of my time dealing with code. In JVM land, I'm spending 30% just dealing with the build system. It's actually insane, and the community at large thinks this is normal. The amount of time it takes to publish a multi-platform Kotlin library for the first time can be measured in days. I published my first Golang library in minutes, by comparison.
- threeseed 2y ago
  > the community at large thinks this is normal Half are ignorant. Other half are like me and just stuck with no options. But the tooling ecosystem on the JVM truly is horrific.
  - iamcalledrob 2y ago
    I think there are a lot of "JVM Lifers" who are so deep in the ecosystem they are unaware how much better things can be. Anecdote: I wanted to publish a ~100LoC multiplatform Kotlin library -- just some bindings. I publish these sorts of things for Go with just a "git push". Steps were: 1. Spend a few hours trying to understand Maven Central/Sonotype, register and get "verified". They're in the middle of some kind of transition so everything is deprecated or unstable. 2. Figure out signing, because of course published packages must be signed. Now I have a secret to keep track of too, great. 3. Discover that there is no stable Gradle plugin for publishing to the "new" Maven Central, it's coming soon... Choose one of the handful of community plugins with a handful of stars on GitHub. 4. Spend a few hours troubleshooting a "Gradle build failed to end" error, which ended up being due to signing not finding a signing key. 3rd party plugin didn't handle errors properly, and a bug in Gradle meant that my secret wasn't picked up from local.properties. 4. Eventually discover that because Kotlin Multiplatform can't be cross-compiled, there is no way to actually publish a multiplatform library without spinning up a bunch of CI runners. And you can't just publish code -- JVM packages have to contain compiled artifacts. 5. Realise this now involves maintaining GitHub Actions and Gradle, which is an ongoing cost. 6. Give up. The harm that this kind of complexity must be causing to the ecosystem is immeasurable.
    - iainmerrick 2y ago
      I’d just like to add, NPM gets a lot of flak (mostly deservedly) but it too is still vastly easier than anything in the JVM ecosystem. Even with all the headaches around modules versus CJS, and JS versus TypeScript, NPM is a lot easier than Gradle. Notably, you have a choice of alternate tools (eg pnpm, yarn, bun) that interoperate pretty well. I guess my point is, Gradle and Maven are specifically and outstandingly bad.
rykad 2y ago
To be blunt, nothing. The issue is that most people in jvm land are on a closed bubble and haven't seen anything else. This is true for build systems as is for non OO design for example. Most simply don't know better and the rest of us are simply stuck. Ant and then Maven started simple enough but people always find a way to justify adding more stuff. Gradle already started complex enough and they keep adding more stuff...
- cryptos 2y ago
  You have to keep in mind that Gradle Inc. earns money by providing consulting for complex builds. An easy build tool would destroy this business model ;-)
  - mrudolph22 2y ago
    They transitioned to a product company 5+ years ago. https://gradle.com https://gradle.com Gradle's complexity comes from at least two places: 1. The original vision of solving complex multi-technology/language Enterprise builds. 2. Poor early design decisions that they never recovered from.
- kaba0 2y ago
  To be blunt, if anything it might be you who live in a closed bubble. Builds that require ad-hoc functionality is the default. It’s extremely rare that everything fits nicely into “cargo build” or other single language build tools’ model. And while these often have escape hatches, at that point you have to write imperative code with no caching and parallelization that is literally the job of a build tool.
  - rykad 2y ago
    I've been doing jvm apps for almost 20yrs... What builds need to do and what people made the builds do are completely different things. I don't remember a single project I was involved in that could not had had a simpler build...
    - 2y ago
dikei 2y ago
In JVM world, the de factor equivalent to `go build` and `go test` are `mvn compile` and `mvn test`, which works 99% percent of the time. Other build tools and plugins just compete/fill in for: * improved build speed / test speed: using background daemon to reduce strtup speed, intelligent caching / task reordering to avoid redoing, etc.. * extra functionalities like code generation, publishing or deployments. As code generation is really big in JVM world, and there are many ways to deploy an application: jar + libs in a zip file, uber jars, container image, etc...
- dcminter 2y ago
  Curmudgeon here: this was true for a relatively brief period of time. Nowadays I'd say that gradle has (inexplicably to me) taken the lead - and everyone adds custom crap to their gradle build making them far less predictable than maven builds used to be. I guess it's better than the nightmare over in the front-enders' world...
  - switchbak 2y ago
    I rarely see Maven files in non-trivial projects that are anything but a confusing mess of XML. Granted, the constrained abilities do tend to keep folks from writing one-off snowflake build customizations, which is nice. But it still leave a hell of a lot to be desired. It was however, leagues ahead of Ant, which wasn't a high bar.
    - dcminter 2y ago
      I saw a lot of that too - I just see more and worse with gradle. Maven gave us two things; good dependency management and convention driven builds (removing the horrible scripted build stuff in Ant). Gradle from my point of view took the second one away again and it feels like it was just because people didn't like XML and couldn't be bothered to learn how Maven's build lifecycle actually worked! Like I say, I'm a curmudgeon...
- pkolaczk 2y ago
  My typical mvn session after a month of not touching maven: % mvn [ERROR] No goals have been specified for this build. Uh. % mvn build [ERROR] Unknown lifecycle phase "build". Uh, nope, that wasn't it.... % mvn compile BUILD SUCCESS Now trying to run the app... Error: app jar not found. Reading the README.md. Aha! So I need to install it! % mvn install 16:59:35,075 [INFO] Building <blahblahblah> [1/32] ... 16:59:38,483 [INFO] ------------------------------------------------------- 16:59:38,483 [INFO] T E S T S 16:59:38,483 [INFO] ------------------------------------------------------- ^C // me searching on google how to not run tests % mvn install -DskipTests=true // now good... Ok, let's run some tests. The FlakyTest broke again in CI. Let me run it locally: % mvn test FlakyTest 17:02:19,481 [ERROR] Unknown lifecycle phase "FlakyTest". Aaargh, ok, googling it again: % mvn test -Dtest=FlakyTest 17:03:16,102 [ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:3.3.0:test (default-test) on project blah blah: No tests matching pattern "FlakyTest" were executed! (Set -Dsurefire.failIfNoSpecifiedTests=false to ignore this error.) The original idea behind maven is nice. But the defaults are so bad, that the whole experience of convention over configuration has been ruined. Cargo and go build systems took the original maven philosophy and implemented them right, with good UX. Gradle, SBT and friends took a step back to the times before maven, and went fully the Ant way, doubling down on "configuration over convention". Where "configuration" is actually "programming in a DSL on top of another language on top of Java".
mike_hearn 2y ago
Build tools sit in an unhappy corner of the design space where they provide features not found in the core of regular programming languages, and which are so generally useful that there's a temptation to make them very abstract, but then they often lack some of the features that let regular programs scale well. The key feature that justifies their existence is parallel and incremental execution of DAGs of world-mutating tasks. This is an awkward fit with most programming languages, hence the prevalence of DSLs. But people don't want their build system to become a general purpose programming language, because they don't want to think about build systems at all and because programmers don't buy programming languages anymore, so, this causes a big design tension between generality (people want to use build systems to automate many things) and deliberately limiting the expressive power to try and constrain the design space and thus tooling investment required. Java is in an awkward place because the JDK was born in the 90s on UNIX, by people who thought make is a sufficiently good solution. You still see remnants of this belief in the official Java tutorials, in JEPs, and in the fact that OpenJDK itself is compiled using an autotools based build system! (fortunately it's one of the nice make based build systems out there). The problem with make is twofold: 1. It assumes a CLI that's both powerful and standardized provided by the host OS. Windows violates this assumption but Java is meant to be portable to Windows. 2. "Plugins" are CLI tools or scripts and so make implicitly assumes that subprocess creation is cheap. But process creation on Windows is expensive, and starting up JVM programs is also expensive due to the JIT compiling. Therefore make just doesn't work well in the JVM ecosystem. At the same time, the Java project wasn't providing any competing solution, so the wider open source community was left to fill in the gaps. These days language developers provide build tooling out of the box as part of the base toolset along with the compiler, but Java still doesn't. So - you ask, what are people doing with Gradle/Maven that requires all those features. The answer is: everything! Gradle builds frequently orchestrate dozens of different tools as part of a build pipeline, build documentation websites, do upload and deployment, download and manage dependencies, run security scanners and license compliance checkers, analyze dependency graphs, modify compiler behaviors, and so on. Additionally Gradle isn't specific to Java, or even JVM apps. It can also be used to compile C/C++ programs, run native code compilers like Kotlin/Native, and it abstracts the underlying platform so Gradle builds aren't tied to UNIX. That's why it's so complicated.
- 2y ago
lihaoyi 2y ago
Author here! `go build` and `go test` do work, at limited scale and complexity. In Scala there's Scala-CLI which is excellent. If they work for you, you probably aren't the target market for these build tools. Once you start layering on bash scripts, layering on make, layering on Python scripts, layering on manual steps written down in a readme.md somewhere, that's the time when you should consider a proper build tool. And if that has never happened to you in your career, count your blessings :) Why not just write some boring, pure code to handle the build? Why not write my build system in vanilla LYAH Haskell? It turns out that builds do have some specific requirements that most programs do not need to care about: caching, parallelization, introspection, and so on. Check out the following blog/talk for more details: * Blog Post: Build Tools as Pure Functional Programs https://www.lihaoyi.com/post/BuildToolsasPureFunctionalPrograms.html https://www.lihaoyi.com/post/BuildToolsasPureFunctionalProgr... * Video: Mill: a Build Tool based on Pure Functional Programming https://www.youtube.com/watch?v=j6uThGxx-18&list=PLBqWQH1MiwBSThMSFV4k4dGTZkS0mfbxo&index=16&t=27s https://www.youtube.com/watch?v=j6uThGxx-18&list=PLBqWQH1Miw... Thus "naively" building your project "directly with code" ends up not working, so you do need some additional support. While most build tools end up constructing a complete bespoke programming environment from scratch, Mill tries to leverage the Scala language and JVM as much as possible, so you can re-use all your expertise and tooling (e.g. IntelliJ, VSCode, Maven Central, etc.) almost verbatim while getting all the necessary build-tool stuff (parallelism, caching, introspection) for free. Check out those two links if you want to learn more!
- potamic 2y ago
  Thanks, the post actually answers my question on build requirements. It's a very good write up overall! If your USP is to solve those layering cases, then why not target other ecosystems like golang/rust as well? Your design philosophy certainly seems to be language agnostic. By calling yourself a build tool for Java and Scala, it gives an impression that this is solving problems specific to those environments, and your adoption also indicates as such. Is it that these communities do not like to adopt such tools or is there something about the JVM ecosystem that tends towards having complex build requirements?
  - 2y ago
kaba0 2y ago
There are quite a few cases: the moment you touch another language, resources that require a compile-step (e.g. xml schemas to code dtos, protonbuf, all that kind of stuff), sometimes even the code itself requires generation.
zem 2y ago
I recommend the "build systems a la carte" paper for a good overview of the various problems build systems address
cyberax 2y ago
Try to build a Go project that uses Cgo and non-trivial C/C++ libraries. Throw in cross-compilation for more fun. You'll end up with an external build system that invokes Go build as one of the steps. Go projects normally just tend to be self-contained server-like software that doesn't need a lot of external libraries. But once you step away from that, you're on your own. I guess my problem with Gradle is that app building should be way simpler than it is. Apps are not something niche anymore, but the tooling is still similar to the embedded software for microcontrollers.

iamcalledrob 2y ago

It's not clear to me how this is better than Gradle. And I hate Gradle. 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're in plugin dependency hell with no idea how anything actually works. - Build scripts written in a DSL on top of a new language: Now I have to learn Scala and your DSL. I don'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

fabioz 2y ago
The first advantage the homepage lists is: > Mill can build the same Java codebase 5-10x faster than Maven, or 2-4x faster than Gradle Speed per se can be a good selling point (having to wait for slow builds is really annoying). I can't really comment on anything else though as I just stumbled upon it here in HN ;)
- iainmerrick 2y ago
  The goal should be more like 50x faster than Gradle. Gradle is ludicrously slow (at least in every single Gradle project I’ve had to work with).
  - kaba0 2y ago
    First invocation may be. Subsequent builds are very fast, unless someone decided to write random bullshit into the build scripts that execute at config time, making the config process impure.
    - iainmerrick 2y ago
      I’m mostly thinking of Android projects. If I have time I’ll try some speed tests with a new basic project. But I don’t think I’ve even once done something in Android Studio and thought “huh, that was surprisingly fast”. Maybe some of the hot reloading stuff is okay (when it actually works).

juangbet 2y ago

[flagged]

cryptos 2y ago

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! https://mill-build.org/mill/0.12.1/comparisons/gradle.html https://mill-build.org/mill/0.12.1/comparisons/gradle.html

lihaoyi 2y ago
Author here. Unfortunately this is because my own experience with Gradle is not up to date; I've only lived in the Gradle Groovy world! If anyone is interested in helping out, I have a 1500USD bounty on porting a gradle.kts build to Mill, so we can do a fair up-to-date comparison https://github.com/com-lihaoyi/mill/issues/3670 https://github.com/com-lihaoyi/mill/issues/3670
- mdaniel 2y ago
  I believe you have influence over the syntax highlighting on GitHub of .mill files by informing it they're actually Scala, which would make reading those files much nicer IMHO: https://github.com/github-linguist/linguist/blob/v8.0.1/docs/overrides.md#using-gitattributes https://github.com/github-linguist/linguist/blob/v8.0.1/docs... Or, I believe you can submit a PR to linguist to make it globally registered: https://github.com/github-linguist/linguist/blob/v8.0.1/CONTRIBUTING.md#adding-an-extension-to-a-language https://github.com/github-linguist/linguist/blob/v8.0.1/CONT...
- imtringued 2y ago
  You can maintain your competitive advantage over gradle by not constantly breaking backwards compatiblity, by the way.
brabel 2y ago
I never got why people thought Kotlin would help Gradle. It absolutely doesn't. Groovy was never the problem (Groovy has types, always had, you could use them if you wanted). Think about it: what do you do with a build tool? You write a little recipe, then you run it. Does that remind something? Yes, it reminds scripts, like bash scripts you run all the time in your terminal. And why are scripts almost universally written without types... and no typed alternative, of which there are many, has caught on? Because if you're just going to modify a script and immediately run it, while keeping it short enough so you can know what it does without reading a book, how does adding types help you? Quite to the contrary, scripts (including build scripts) should be small, and having types all over the place make it far more verbose than it should be, likely pushing it out of your comfortable local memory in your brain, at which point you need something akin to a "real" programming language and a compiled program, not a script. Larger programs benefit from types because you don't just run the program, make changes, and run them again, like you do with scripts. You write them, test them, compile them, package them and finally you distribute them to your users who hopefully only need to configure them, not modify their internals. If your build is that complex, that's exactly what you should be doing instead of trying to shoehorn types into your scripts and expecting them to look like real programs. Also, the Kotlin DSL just doesn't assist in the most problematic aspect of Gradle: its total lack of discoverability. Try doing something on your Kotlin Gradle file using a plugin you're not familiar with (which is all of them for most of us). It's completely impossible unless you know the DSL of the plugin, just like it was the case with Groovy... Once you know the DSL, it's fairly easy, but even in Groovy you will get auto-completion once you've got to the DSL "entry point", no need for Kotlin. I've been saying this since before they introduced the Kotlin DSL, and now i feel completely vindicated. I've never met anyone who told me "Gradle is so much easier now with Kotlin". But it did mess up plugins I wrote in Kotlin as now Gradle has a dependency on a very particular version of the Kotlin compiler, and God help you if your plugin was written with a different version in mind.

jiehong 2y ago

Why not compare it to bazel/pants/buck2 as well? Mill seems to have taken some inspiration from those as well.

lihaoyi 2y ago
Author here. It does! I started working on Mill when I started learning Bazel, during my first months at Databricks. There's a lot of cross-pollination of ideas there, from my 7 years adopting and maintaining the Bazel build at Databricks, but I haven't had time to do a proper head-to-head comparison. Hopefully someone else can though!
- wocram 2y ago
  What drove you away from Bazel? I would expect anyone considering migrating away from a "legacy" tool like maven would consider a "modern" tool like Bazel first.
  - lihaoyi 2y ago
    Bazel is a rats nest of complexity. In my experience it does what it does very well once set up, but setting it up is tremendously complicated, much of it IMO incidental complexity. Rolling out Bazel at my prior employer tool about one person decade of engineering time. I've talked to other companies that tried to roll it out and failed. Bazel is hard And Bazel is not really getting any easier! Like most projects, it is getting more complex over the years as features acrete. I think there is space for a tool like Mill for less sophisticated users who can't afford to spend a person-decade rolling out their build tool
    - robert-brown 2y ago
      There's a big difference between the complexity of setting up Bazel and the experience of using Bazel at a company where Bazel has been set up for you. As a user I love Bazel. When working with Java, I use the java_binary and java_library rules. When coding in Go, there's nothing new to learn regarding the build, just use go_binary and go_library instead. Everything is repeatable, builds and tests are cached, it's easy to query the build dependency tree, etc. A few startups are offering "Bazel build/test as a service." It's one way to eliminate the work involved in setting up Bazel for an organization.

lihaoyi 2y ago

Author here! Hope you take a look at the project and find it cool. There'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: * https://www.youtube.com/watch?v=UsXgCeU-ovI https://www.youtube.com/watch?v=UsXgCeU-ovI 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 https://mill-build.org/mill/0.12.1/extending/new-language.html https://mill-build.org/mill/0.12.1/extending/new-language.ht... 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 Design Principles 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: * Mill Design Principles https://mill-build.org/mill/0.12.1/depth/design-principles.html https://mill-build.org/mill/0.12.1/depth/design-principles.h... I'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 I'm also trying to get the community involved, so it'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'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! https://github.com/orgs/com-lihaoyi/discussions/6 https://github.com/orgs/com-lihaoyi/discussions/6

philipwhiuk 2y ago
The current version is 0.12.1. What's required for v1.0?
- lihaoyi 2y ago
  Traditionally I've labelled my OSS projects 1.0 when they've stabilized and the rate of change has greatly reduced. Right now Mill is not there yet, but maybe if at end-2025 we realize no breaking changes have been needed since end-2024, we can call it 1.0

sireat 2y ago

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

k3vinw 2y ago

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. The main appeal that I can see from mill over maven is the power of dynamic programming over static xml files. Maybe good lsp/ide support will make managing a build system like this bearable?

lihaoyi 2y ago
Yes, IDE support in Mill is key. Without IntelliJ or VSCode, Mill would not be nearly as pleasant to use as it is today. Mill and Maven both let you declare goals for what you want to do. One does it in XML and one does it in typechecked code. While XML does work, doing things in code with typechecking and full IDE support turns out to be pretty nice as well!

msl09 2y ago

Nice try, I'm still not going to write scala code.

galdosdi 2y ago
Build times always were my biggest Scala complaint. Arguably code base specific, as I suspect it had a lot to do with all the macros and type level metaprogramming, but, if that kind of thing is possible and customary, an average working programmer who doesn't control the codebase they show up to is going to end up stuck dealing with it. It's a lot easier to build a language that works great, but only in the hands of a single skilled careful owner, than a language that stands up to the abuse of many careless temporary users, and still gets from point A to point B reliably. Like the difference between a sportscar and a rental company or police fleet sedan. Scala was a porsche, but most of us need camrys.

whoodle 2y ago

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. Has anyone at the senior level recently moved on from Scala to other languages recently? Any issue finding jobs or learning the new role?

deleted 2y ago
[deleted]

pnathan 2y ago

I've used mill for some Scala projects in the past and I give it 5/5.

carrotsalad 2y ago

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's a significant cognitive burden to understand and manage something that one hopes to not have to think about very often. I find that the pain I experience with Gradle isn't usually about how to do something clever or customized etc, but instead it's when I haven'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's groovy, Kotlin, or some aspect of the build DSL - since my mind has unloaded everything about Gradle in the meantime. 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.

beeboobaa3 2y ago
My problem with gradle is that its configuration language is a programming language. Sounds amazing in practice. And it is. Until you need to fix a 3 year old build that has some insane wizardry going on.
- mdaniel 2y ago
  > Until you need to fix a 3 year old build that has some insane wizardry going on. My experience with Gradle is that it's the "3 year old build" that is almost certainly a death knell more than the insane wizardry part. My experience: git clone .../ancient-codebase.git cd ancient-codebase ./gradlew # <-- oh, the wrapper, so it will download the version it wants, hazzah! for _ in $(seq 1 infinity); do echo gradle vomit you have to sift through; done echo 'BUILD FAILED' >&2 exit 1 Contrast that with https://github.com/apache/maven-app-engine https://github.com/apache/maven-app-engine (just to pick on something sorted by earliest push date, some 10 years ago): $ git clone https://github.com/apache/maven-app-engine.git $ cd maven-app-engine $ mvn -B compile [INFO] ------------------------------------------------------------- [ERROR] COMPILATION ERROR : [INFO] ------------------------------------------------------------- [ERROR] error: Source option 6 is no longer supported. Use 8 or later. [ERROR] error: Target option 6 is no longer supported. Use 8 or later. [INFO] 2 errors $ echo "Java gonna Java" $ git grep -n source.*6 pom.xml:133: <source>1.6</source> $ sed -i.bak -e 's/1.6/1.8/g' pom.xml $ mvn -B compile [INFO] BUILD SUCCESS

mrudolph22 2y ago

I gave Mill a try earlier this year. My hope was to escape the nightmare that is Gradle, which I've been using for many years. Mill sounds great in theory (except for the Scala DSL). Unfortunately, I couldn'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't ready. There was also very little documentation on how to build Java. In my opinion, using a GPL as the build language of a polyglot build tool is a dead end, both for technical/usability reasons and because the ensuing language wars can't be won. I'm looking forward to the day when a build tool embraces a modern config language such as CUE or Pkl.

lihaoyi 2y ago
Depending on when you tried, it could be worth trying again: support for Java has improved greatly in the last few months, as have the documentation. Come by our discord channel if you get stuck and i can help unblock you
- mrudolph22 2y ago
  Thanks for the offer! I’ll give Mill another shot the next time Gradle drives me crazy. :-)
zcw100 2y ago
I've had the same gripe about having to keep up with a second language just for the build tool for a while. Try taking a look at JeKa https://jeka.dev/ https://jeka.dev/

PaulHoule 2y ago

Speed wins for dev tools. 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. 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 not 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?)

thefaux 2y ago

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'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'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. 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).

weego 2y ago
sbt is one of the worst engineering mistakes I've ever witnessed. It was a constant source of esoteric ergonomics and frustration for no clear reason other than being the pet project of someone who really loved implicits.
lihaoyi 2y ago
The test thing is just a matter of defaults, in Mill subprocess testing is the default and in-process testing opt-in via .testLocal. I also believed that a lot of existing JVM tooling is bloated and slow, so we are in agreement! Mill tries to be different, so do give it a chance if you can. There is life beyond Maven, Gradle, and SBT

TeaVMFan 2y ago

It's great to see continuing innovation in the Java space! One tool I've been using to speed up maven is mvnd, the maven daemon. It's a drop in replacement for mvn with impressive speedups. https://github.com/apache/maven-mvnd https://github.com/apache/maven-mvnd

speed_spread 2y ago
I'm not sure I like the daemon approach. But the cache extension provided me fantastic gains: https://github.com/apache/maven-build-cache-extension https://github.com/apache/maven-build-cache-extension
- lihaoyi 2y ago
  Mill uses the same daemon design as Gradle and mvnd. You do hit edge cases occasionally, but overall it works great

Raydat 2y ago

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's builds so much easier going through it step by step

khana 2y ago

[dead]

BillLucky 2y ago

Sounds great!