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

141–150 of 168 posts

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

#141

Post by elygre »

rykad wrote: post #51
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.

I've been doing jvm apps for almost 20yrs... What builds need to do and what people made the builds do are completely different things. I don't remember a single project I was involved in that could not had had a simpler build...

True. In our example we didn’t have to generate online help and pdf manuals from the same asciidoctor sources. But when we chose to, we really needed the customization that cradle offered.

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

#142

Post by cyberax »

lihaoyi wrote: post #135
cyberax wrote: post #115

Earlier quoted context omitted.

> 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

Sure. But adding ability to self-modify the build drastically increases the complexity of a build tool. Maven developers decided that they want to avoid that.

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

#143

Post by mrudolph22 »

lihaoyi wrote: post #123
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

Thanks for the offer! I’ll give Mill another shot the next time Gradle drives me crazy. :-)

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

#144

Post by hocuspocus »

switchbak wrote: post #116
ktosobcy wrote: post #65

Earlier quoted context omitted.

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.

Mill's early goal was to be a saner sbt, incidentally also fixing the parts of sbt that are/were unreasonably slow due to questionable design decisions.

Maven has never been relevant to the Scala ecosystem given most of the community has pretty much moved straight from ant to sbt. Only a few Spark related projects stubbornly use Maven, which is a major pain given the lack of cross-building abilities. Slow dependency resolution and inefficient use of Zinc merely add insult to injury.

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

#145

Post by lihaoyi »

wiradikusuma wrote: post #56
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…

Does it support Quarkus (esp. native build)?

It should! I haven't had a chance to create an example myself yet, but there's a 500USD bounty open if anyone wants to take a crack at it https://github.com/com-lihaoyi/mill/issues/3549

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

#146

Post by kelnos »

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…

Not the author, but this is unfortunately a bit more difficult than it sounds. Like for example, where do you get the name of the jar file to build? I guess you could use the name of the root directory, but that may not be ideal.

How do you figure out dependencies? Import statements in .java files give you the packages to import, but those package names could be provided by one or more .jar files and, regardless, the package names need not bear any relation to the jar name or its group/artifact IDs (if pulling from e.g. a maven-style repository, which basically everyone does).

For multi-module projects, how do you figure out the dependencies between the modules, even? Sure, you could probably figure that out by parsing all the .java files in all modules and figuring out what they provide and import, but that would be slower than maven, probably.

You could certainly do this for small, dependency-free programs, but it would be such a niche use case that I don't think it would be worth the time.

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

#147

Post by rileymichael »

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.

How does that differ from `gradle init`?

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

#149

Post by ackfoobar »

iainmerrick wrote: post #129
ackfoobar wrote: post #89

Earlier quoted context omitted.

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

I have no complaints for the well trodden path (e.g. https://github.com/google/protobuf-gradle-plugin). I have also written some custom build steps, and indeed the docs aren't very helpful - but the final implementation is quite simple.

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

#150

Post by usrusr »

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…

Npm also gets a lot of flak for the low bar it sets for introducing malicious code by impersonating an idling maintainer or presenting yourself as a successor. The friction, the secrets to keep, they are there for a reason.
Post reply on HN