Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mill: A fast JVM build tool for Java and Scala

mill-build.org

Post reply on HN
Print view View original

121–130 of 168 posts

Re: Mill: A fast JVM build tool for Java and Scala

#121

Post by lihaoyi »

wocram wrote: post #60
lihaoyi wrote: post #26

Earlier quoted context omitted.

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!

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.

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

Re: Mill: A fast JVM build tool for Java and Scala

#122

Post by lihaoyi »

carrotsalad wrote: post #66

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 h…

Even in Java, because the language is relatively verbose, many frameworks fall back to an "inner platform" of magic annotations which have the same problem: e.g. just because you know how Java works doesnt mean your mind hasn't unloaded all the SpringBoot annotation semantics! But despite that it is worth it, because conciseness does matter.

Mill using Scala syntax is like that, but with the added advantage that even if you forget how Scala works, your IDE does not. You can really lean on Intellij or VScode to help you understand and navigate around a Mill build in a way that is beyond what is possible for most build tools: You can autocomplete things, peek at docs, navigate the build graph and module tree, etc. and learn what you need to learn without needing to reach for Google/ChatGPT. I use this ability heavily, and I hope others will enjoy these benefits as well

Re: Mill: A fast JVM build tool for Java and Scala

#123

Post by lihaoyi »

mrudolph22 wrote: post #73

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…

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

Re: Mill: A fast JVM build tool for Java and Scala

#124

Post by dcminter »

switchbak wrote: post #117
dcminter wrote: post #55

Earlier quoted context omitted.

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

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.

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

Re: Mill: A fast JVM build tool for Java and Scala

#125

Post by brabel »

iamcalledrob wrote: post #28
user1241320 wrote: post #11

Earlier quoted context omitted.

One note from having worked with both that I don’t see mentioned: Golang dependencies are sources you basically pull and compile with your own code. In JVM-land dependencies are precompliled packages (jars). This adds one little step.

...or a big step, if cross-compiling is required (e.g. Kotlin Multiplatform) I'm surprised there is no source-only dependency solution for JVM -- it'd solve this issue. Pull down the source and build on the fly. Perhaps there is and I'm unaware?

What issue would it solve? The fact that you can build a jar in any OS and then just use that anywhere else is actually a huge benefit of using Java, as you don't force everyone to re-compile your library source code.

Re: Mill: A fast JVM build tool for Java and Scala

#126

Post by layer8 »

lihaoyi wrote: post #25

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 While Mill is focusing on JVM for now, it is very extensible and I have a s…

I couldn’t quickly find how dependency resolution and versioning works in Mill. Can you give any pointers?

Also, what’s with the “ivy” on https://mill-build.org/mill/0.12.1/comparisons/maven.html ? Any relation to Apache Ivy?

Re: Mill: A fast JVM build tool for Java and Scala

#127

Post by brabel »

pkolaczk wrote: post #67
iamcalledrob wrote: post #5

Earlier quoted context omitted.

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 no…

I've been working on Java-based systems for about 20 years now, and I fully relate to that. Same experience. This is so annoying that I prefer to use Rust over Java even in areas where things like better performance or better type system don't matter. But being able to start a fresh project with one `cargo init` and a few `cargo add` invocations to add any dependencies... well, this is priceless.

Interesting that you ended up going all the way to Rust land instead of just using one of the multiple tools that have been created to help with this, like:

* Spring Boot (it has a UI to create projects where you pick Java version, DB, build tool, some libs etc): https://spring.io/guides/gs/spring-boot

* JHipster - the nuclear option, pick what you want a la carte: https://www.jhipster.tech/

* JBang - a cute CLI for this: https://www.jbang.dev/

* Maven Archetypes - the old fashioned way (existed before "create-app" kind of tools appeared): https://maven.apache.org/guides/introduction/introduction-to...

And most IDEs also have "new project" wizzards.

Re: Mill: A fast JVM build tool for Java and Scala

#128

Post by robert-brown »

lihaoyi wrote: post #121
wocram wrote: post #60

Earlier quoted context omitted.

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.

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…

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.

Re: Mill: A fast JVM build tool for Java and Scala

#129

Post by iainmerrick »

ackfoobar wrote: post #89
iainmerrick wrote: post #17

Earlier quoted context omitted.

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…

I must be missing something here. Don't the tools you mentioned do a lot less than Gradle? Gradle knows test depends on compile, which depends on code generation (say protobuf) - with caching and change detection. Compare that to chaining up the commands in the `scripts` section of `package.json`. EDIT: another comment making this point: https://news.ycombinator.com/item?id=41969847

I could be convinced if those features of Gradle actually worked well, or even worked properly, like dependency management does in e.g. Bazel.

In practice, Gradle really seems to fall down on the basic task of just being able to build stuff in the first place. It feels like you’re constantly fighting version hell just to find a Gradle version and plugins that work together, let alone your actual code dependencies.

And if you actually do need to do something slightly more complicated, like code generation, it’s very difficult to work with and the docs are really bad.

Re: Mill: A fast JVM build tool for Java and Scala

#130

Post by brabel »

pkolaczk wrote: post #72
philipwhiuk wrote: post #43

Earlier quoted context omitted.

> I published my first Golang library in minutes, by comparison. For what platform(s)? Or did you really just push the source code?

That's the trick. You publish the source code. And it's still faster to build all dependencies from source than maven / gradle manages to resolve and download the binary dependencies ;)

That's true, Maven is ridiculously slow to resolve dependencies while Gradle only really works with reasonable speed if you allow it to hog your system with a deamon.

I myself wrote a dependency resolver that matches Maven in functionality, and even a large project that uses Spring Boot and its dozens of dependencies can be resolved in a couple of seconds. About 10x faster than Maven or something like that. If you look at Maven's source code you'll see why. It's the worst kind of Java Enterprise overengineering you can imagine, complete with its own dependency injection framework, everything is pluggable (for no reason, really, do you really need to replace HTTPS for your protocols?? In Plexus you can), to the point that all the de-coupling results in lots of things duplicating functionality everywhere. I am not sure but I would bet Maven parses your POM at least 10 times to do anything due to the de-coupled nature of it.

Post reply on HN