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

101–110 of 168 posts

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

#101

Post by mrudolph22 »

cryptos wrote: post #14
rykad wrote: post #10

Earlier quoted context omitted.

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

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

They transitioned to a product company 5+ years ago. 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.

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

#102

Post by cyberax »

dkarl wrote: post #91
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.

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.

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

#103

Post by thefaux »

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

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

#104

Post by zem »

potamic wrote: post #4

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

I recommend the "build systems a la carte" paper for a good overview of the various problems build systems address

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

#105

Post by vips7L »

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

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.

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

#106

Post by pkolaczk »

kaba0 wrote: post #86
pkolaczk wrote: post #69

Earlier quoted context omitted.

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.

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 project. It took 57 seconds.

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

#107

Post by cyberax »

potamic wrote: post #4

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

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.

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

#108

Post by pkolaczk »

mdaniel wrote: post #88
pkolaczk wrote: post #67

Earlier quoted context omitted.

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

But I don’t want to copy a full project with prepopulated list of dependencies chosen by someone else. I want to start small and add dependencies I need.

It’s like LEGO vs Playmobil. I want LEGO. ;)

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

#109

Post by weego »

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…

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.

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

#110

Post by pkolaczk »

Calzifer wrote: post #87
pkolaczk wrote: post #64

Earlier quoted context omitted.

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

When I want to run tests, I tell it to run the tests. When I want to install, I tell it to install. I don’t want it to run tests when I tell it to install. I don’t want tools who know better what I want to do than me.
Post reply on HN