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

131–140 of 168 posts

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

#131

Post by lihaoyi »

layer8 wrote: post #126
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?

Dependency resolution uses Coursier, which is one of the open source JVM dependency resolvers. SBT uses it too, and my last company used it with Bazel

The "ivy" thing is legacy haha. Mill used to use Apache Ivy to resolve dependencies, years ago. Coursier was a better/faster replacement, but names have a tendency to stick around

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

#132

Post by lihaoyi »

jackcviers3 wrote: post #83
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…

The intention has changed, Mill now explicity targets Java and Kotlin as well. It now has dedicated Java/Kotlin docsite sections and examples, and has grown integrations with Palantir-Format, Checkstyle, Errorprone, Jacoco, and all their Kotlin equivalents (ktfmt, ktlint, kover).

Java and Scala (and Kotlin) are remarkably similar from a tooling perspective, so Mill tries to target both using the same shared infrastructure

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

#133

Post by lihaoyi »

thefaux wrote: post #103

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

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

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

#134

Post by lihaoyi »

skybrian wrote: post #59
lihaoyi wrote: post #33

Earlier quoted context omitted.

Author here! The issue here is that builds, and many other "just configuration" scenarios, are fundamentally complex. So many projects that start off as "just XML" or "just YAML" end up implementing their own half-baked programming language interepreter inside of their XML/YAML/JSON/whatever. Examples: * Github Actions Config Expressions https://docs.github.com/en/actions/writing-workflows/choosin... * CloudFormation…

I agree that Bazel did pretty well with Starlark, but the reason that’s sane is because it’s not Python, though the syntax is similar. It avoids getting into trouble with people using Python language features that would result in upgrade hell and annoy other programmers who aren’t Python experts. (Though, debugging complicated Starlark code can still be difficult.) So why not use Starlark? :)

Starlark is great, but so is Scala. People underestimate how big the ecosystem is even for a niche language like Scala:

- Global publishing and distribution infrastructure

- IDE support in multiple IDEs

- A huge ecosystem of third party packages, both Scala and Java

- An excellent Scala standard library and Java standard library

- Good performance.

- Tooling! Jprofiler is great. Others use Yourkit or JFR.

- Mill leans havily on Scala's FP/OO hybrid style with types, while starlark provides none of that and is purely untyped procedural code

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

#135

Post by lihaoyi »

cyberax wrote: post #115
dkarl wrote: post #114

Earlier quoted context omitted.

When I used Maven, extensions had to be published to and pulled from a public repo. We couldn't even use the private repo that we used for the rest of our libraries, because the extension had to be loaded before Maven read the file where our private repo was configured. Whereas a Gradle build can read Groovy files straight from disk.

> When I used Maven, extensions had to be published to and pulled from a public repo. You can just `mvn install` them locally into your local repository.

You can, but why should you need to? Why can't the build tool take the plugin code directly off of disk, build it, and use it? This kind of orchestration of manual steps is what build tools are meant to be good at

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

#136

Post by lihaoyi »

speed_spread wrote: post #119
TeaVMFan wrote: post #113

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

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

Mill uses the same daemon design as Gradle and mvnd. You do hit edge cases occasionally, but overall it works great

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

#137

Post by mdaniel »

dkarl wrote: post #114
cyberax wrote: post #102

Earlier quoted context omitted.

> it can't be local to the project It certainly can be, in the same repository.

When I used Maven, extensions had to be published to and pulled from a public repo. We couldn't even use the private repo that we used for the rest of our libraries, because the extension had to be loaded before Maven read the file where our private repo was configured. Whereas a Gradle build can read Groovy files straight from disk.

As the most extreme counterexample of your ... experience[1], someone made a plugin that allowed writing pom files in languages other than XML: https://github.com/takari/polyglot-maven/tree/polyglot-0.7.2...

With an especial nod to https://github.com/takari/polyglot-maven/tree/polyglot-0.7.2... given this submission

1: I believe that you encountered errors, programming is packed to the gills with them, but correlation is not causation in that just because it did not immediately work in your setup does not mean it's impossible or forbidden

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

#138

Post by lihaoyi »

brabel wrote: post #130
pkolaczk wrote: post #72

Earlier quoted context omitted.

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

Maven is actually pretty behind in terms of JVM dependency resolution. Mill uses Coursier, same as my last company did, and when my last company switched from Maven to Coursier we saw a 2 order of magnitude speedup, with resolution commands that used to take 30min finish in a few seconds to give the exact same artifacts and versions.

I actually have no idea why these other resolvers are so slow, or why Coursier is so fast, but this slowness is very much a "maven" or "gradle" thing rather than a "jvm" thing. And Mill using coursier does significantly better!

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

#140

Post by mdaniel »

iamcalledrob wrote: post #112
vips7L wrote: post #105

Earlier quoted context omitted.

Sometimes barrier to entry is good. For example, both npm and cargo struggle with package name squatting and malicious packages that are miss spellings of common packages.

This isn't an issue in the Go ecosystem, because the package name is the GitHub repo. I don't think a high barrier to entry is overall good, in fact I think it encourages larger more complex packages to justify the maintenance burden

Pedantically, that's only one way to resolve a go package - and for sure the more obvious[1] - but the most famous one I know of is gopkg.in/yaml.whatever that uses a tag to redirect to its actual GH repo, which only the deepest golang ninja would know how to use: compare view-source:https://gopkg.in/yaml.v3 with view-source:https://gopkg.in/yaml.v3?go-get=1

1: err, modulo that go.mod stuff that secretly adds a version slug to an otherwise normal github URL -- I'm looking at you, Pulumi: https://github.com/pulumi/pulumi/blob/v3.137.0/sdk/go.mod#L1

Post reply on HN