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

111–120 of 168 posts

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

#111

Post by kaba0 »

pkolaczk wrote: post #106
kaba0 wrote: post #86

Earlier quoted context omitted.

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.

But you’re likely comparing on different hardware though. Go compiling only 16k lines per second is hard to believe for me. Maybe they meant on single CPU core. Rustc compiles over 50k lines per second on my MBP in debug mode and Go must be definitely faster, as everyone knows rust is very slow to compile. But anyway, you may be right. I just ran mvn install for the second time with no source change on my current pro…

The java metric is also from a single core. But you are probably right that it should only be taken as a rough ballpark, but java is definitely in the same ballpark as go in compile speed.

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

#112

Post by iamcalledrob »

vips7L wrote: post #105
jitl wrote: post #47

Earlier quoted context omitted.

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

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

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

#114

Post by dkarl »

cyberax wrote: post #102
dkarl wrote: post #91

Earlier quoted context omitted.

Having worked with Maven and Gradle, I'd say Gradle was worse in the average case, but better in the worst case. There are way more Gradle projects with unnecessary custom build code because Gradle makes it easy to do. On the other hand, when builds are specified in a limited-power build config language, like POM, then when someone needs to do something custom, they have to extend or modify the build tool itself, whi…

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

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

#115

Post by cyberax »

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.

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

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

#116

Post by switchbak »

ktosobcy wrote: post #65
fabioz wrote: post #12

Earlier quoted context omitted.

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 ;)

AFAIR author made quite unfair comparison with simple compile vs full maven build (that executes a lot of additional stuff)

For Scala (of which this is probably the main target) Maven builds are especially slow. I would not be surprised if that was his early focus.

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

#117

Post by switchbak »

dcminter wrote: post #55
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…

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.

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

#118

Post by speed_spread »

fabioz wrote: post #12
iamcalledrob wrote: post #7

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

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 ;)

Are we talking about Maven with its cache extension?

https://github.com/apache/maven-build-cache-extension

Because in my experience, this makes Maven very, very fast.

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

#119

Post by speed_spread »

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

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

#120

Post by kaba0 »

mike_hearn wrote: post #100
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…

Not to defend Gradle too much, but Groovy is a superset of Java. So if you want, you can just use the regular Groovy dialect and then write Java in your build scripts, it should work. This is not entirely a solution though, because Gradle's APIs are fairly complicated and change regularly.

(Nitpick, but it’s just a “superficial” superset. The biggest difference is probably doing “multi-methods”, aka the runtime type of an argument deciding which method implementation to call vs java’s static overload resolution.)
Post reply on HN