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

81–90 of 168 posts

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

#81

Post by hocuspocus »

jitl wrote: post #50
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…

How possible is it to make your tool "zero-config" by default? I see a lot of comments in this thread and elsewhere on twitter asking for essentially `go build`, `go fmt`, `go test` for Java/JVM. I think the language has quite strong convention around directory layout and file naming already, so do you think it would be possible for mill or a mill wrapper to offer the same kind of standardized zero config workflow? I…

Scala CLI has replaced the default runner since Scala 3.5, so you can effectively do `scala run`, `scala fmt`, and so on. On the Java side, I believe JBang provides a very similar developer experience.

Fundamentally it's hard to reconcile both worlds though. Building non-trivial multi-module projects on the JVM is inherently complex especially when you throw in multiple build targets, multiple toolchains, multiple platforms...

With simpler build tools (like in Go or Rust) you shift this complexity elsewhere, typically in a Makefile and/or a Docker/OCI based build pipeline, and these can get pretty complex too. Let alone distributed build tools like Bazel.

- https://scala-cli.virtuslab.org

- https://www.jbang.dev

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

#82

Post by kaba0 »

pkolaczk wrote: post #62
kaba0 wrote: post #34

Earlier quoted context omitted.

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.

> It’s extremely rare that everything fits nicely into “cargo build” 161538 crates do not agree with you ;)

Which are mostly small, isolated library code, whose purpose is to be easily incorporated into larger programs. That’s the 90% easy path of build tools.

What about a large project built over 6 years by 50 people, and that has to use some obscure technology to communicate with company A, and another one that has an idiotic build step?

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

#83

Post by jackcviers3 »

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…

It's intended as a replacement for _scala_ builds. Having a build definition in the native language that doesn't require a different syntax (like a declarative syntax such as maven xml or toml) makes task customization easier for the maintainer of a given project. Unfortunately, it also means that you have to know the language and read the documentation for the build system.

If you want something declarative, there's also bleep[1] in the scala ecosystem. And for single module builds there's scala-cli[2]. It's also possible to use gradle and maven for scala projects, but for an java-only shop I wouldn't be using mill or bleep because there's no need to introduce a new language just to manage the build. For scala/java/kotlin hybrid projects though, gradle or mill or sbt would be my recommended tool because of how tightly they are coupled with the cross-platform build matrix nature of scala library and build system plugin ecosystems. For larger builds, it's mill or bazel because there s a performance cliff in sbt and gradle, and bleep is too new to have all the standard plugins ported. We use mill at writer.

1. https://bleep.build/docs/

2. https://scala-cli.virtuslab.org/

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

#84

Post by brabel »

mdaniel wrote: post #77
beeboobaa3 wrote: post #70

Earlier quoted context omitted.

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.

> 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 # &2 exit 1 Contrast that with https://github.com/apache/maven-app-engine (just to pick on something sorted by earliest…

I dislike Gradle as much as you probably do, but between Maven and Gradle, the one that "vomits" stuff on the command line is definitely Maven. Gradle errs by going too far to the other end: it just doesn't log anything at all, even the tasks that are actually being run (vs skipped... do you know how to get Gradle to show them?? It's `gradle --console=plain`, so obvious!! Why would anyone complain about that, right?!) or the print outs you add to the build to try to understand what the heck is going on.

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

#85

Post by vvillena »

jitl wrote: post #50
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…

How possible is it to make your tool "zero-config" by default? I see a lot of comments in this thread and elsewhere on twitter asking for essentially `go build`, `go fmt`, `go test` for Java/JVM. I think the language has quite strong convention around directory layout and file naming already, so do you think it would be possible for mill or a mill wrapper to offer the same kind of standardized zero config workflow? I…

There's scala-cli, which has become the default Scala run command since Scala 3.5 but is also available separately. It has all those bells and whistles and allows scripts to grow organically. And no matter the name, it handles Java code too.

With scala-cli, there's not even a need to download a Java runtime or a language distribution. You can let the runner do its thing, or pass options to choose the JVM and the language version to use, or even write those options into special headers in the code files. You can also write tests, format code... it's all built-in. And in cases the code outgrows the tool and there's a need to migrate to a different build tool, there's even a feature to export the build to Sbt or Mill.

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

#86

Post by kaba0 »

pkolaczk wrote: post #69
iamcalledrob wrote: post #28

Earlier quoted context omitted.

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

I'm afraid Java/Scala/Kotlin compilers are too slow to make that convenient. Even currently building pure Java projects can take minutes when it's compiling just like 300k lines. What if it had to compile millions of lines from all the dependencies?

The actual compilation step is 100% not the bottleneck - it can go as fast as 10k-50k lines per second! (According to the Mill benchmark, but that’s the Mill-independent part).

Comparatively, Go does “only” 16k lines per second based on some HN comments.

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

#87

Post by Calzifer »

pkolaczk wrote: post #64
dikei wrote: post #18

Earlier quoted context omitted.

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

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 [1/32] ... 16:59:38,483 [INFO] -----…

> [ERROR] No goals have been specified for this build.

> [ERROR] Unknown lifecycle phase "build".

And somehow missed that the error message also lists the valid lifecycle phases. (could have instead complained that it list all lifecycle phases which is a lot)

> // me searching on google how to not run tests

How do I know for other build tools how to skip tests? Skipping tests should not be necessary and is done to regularly. I would not consider a tool which immediately points out how to ignore those stupid tests as good UX.

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

#88

Post by mdaniel »

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.

Are you aware of Maven Archetypes[1]? I believe they were the "cookiecutter" before cookiecutter existed, although I am 10000000% on-board that their discovery story is total garbage :-(

1: https://maven.apache.org/archetype/index.html and https://maven.apache.org/archetype/maven-archetype-plugin/us...

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

#89

Post by ackfoobar »

iainmerrick wrote: post #17
iamcalledrob wrote: post #9

Earlier quoted context omitted.

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…

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

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

#90

Post by mdaniel »

jitl wrote: post #47
dikei wrote: post #20

Earlier quoted context omitted.

> 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. It's a bit Apple & Orange comparison: publishing a JVM only Kotlin library is quite easy, it's the multiplatform part that takes time.

Last time I published a JVM library I had to Open A Jira Ticket to request the rights to publish a package on the main package registry. Then I had to verify I owned the DNS name prefix for my package by fiddling the DNS records at my hosting provider. It took days just to get authorized! Not including the time needed to like, figure out how to make JARs happen. In go: `git push` to a public repo In js: `npm publish`…

Merely as a "for your consideration," GitLab ships with its own Maven repository (along with npm, docker, Nuget, and a bazillion others)[1] so you have total sovereignty over the publishing auth story. I can appreciate going with Central can be a DX win if you're distributing a library, since having folks add lines to their pom.xml or settings.xml is a hassle, but at least you get to decide which hassle you prefer :-D

In fairness, GitHub also finally got on board the train, too: https://docs.github.com/en/actions/use-cases-and-examples/pu...

1: https://docs.gitlab.com/ee/user/packages/maven_repository/

Post reply on HN