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

31–40 of 168 posts

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

#31

Post by iamcalledrob »

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

Although a lot of it is generic badness, Kotlin Multiplatform isn't the JVM ecosystem. You don't need CI runners to publish a JVM library. The reason it comes up with Multiplatform is because Kotlin defines "Multiplatform" to mean platforms like JavaScript, or their own LLVM based compiler toolchain that bypasses JVMs entirely.

Very true, although it definitely feels like part of the ecosystem since it uses the same project structure, build tooling etc.

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

#32

Post by kaba0 »

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

There are quite a few cases: the moment you touch another language, resources that require a compile-step (e.g. xml schemas to code dtos, protonbuf, all that kind of stuff), sometimes even the code itself requires generation.

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

#33

Post by lihaoyi »

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…

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 Functions https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGui...

* Helm Chart Templates https://helm.sh/docs/chart_best_practices/templates/

There is a reason why Bazel went with Python/Starlark, why Pulumi and CDK and friends are getting popular. Fundamentally, many of these use cases look surprisingly like programming languages: maybe not immediately, but certainly after you've dug in a bit. And having a properly designed purpose-build programming language (e.g. StarLark) or a flexible general purpose language (e.g. Typescript, Kotlin, Scala) does turn out to be the least-bad option

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

#34

Post by kaba0 »

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

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…

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.

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

#35

Post by sireat »

Just a note that the author Li Haoyi is a fantastic contributor to Scala community.

He has written multiple useful libraries. Out of many JSON libraries, his one was the most intuitive and practial.

His book is excellent too. I bought it when it came out. It is worthy of a plug: https://www.handsonscala.com/

I miss working on Scala projects. Sadly I rarely see new ones these days.

Does IntelliJ plugin finally work on Scala 3? About 2 years ago it was half broken.

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

#36

Post by AtlasBarfed »

mike_hearn wrote: post #21
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.?

Build tools sit in an unhappy corner of the design space where they provide features not found in the core of regular programming languages, and which are so generally useful that there's a temptation to make them very abstract, but then they often lack some of the features that let regular programs scale well. The key feature that justifies their existence is parallel and incremental execution of DAGs of world-mutat…

Build systems exist in two turning complete rabbit holes/ slippery slides:

Configuration and workflow execution.

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

#37

Post by k3vinw »

The thing that’s great about maven is its declarative nature. You can declare goals and profiles for whatever you need the build system to do.

The main appeal that I can see from mill over maven is the power of dynamic programming over static xml files. Maybe good lsp/ide support will make managing a build system like this bearable?

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

#38

Post by lihaoyi »

k3vinw wrote: post #37

The thing that’s great about maven is its declarative nature. You can declare goals and profiles for whatever you need the build system to do. The main appeal that I can see from mill over maven is the power of dynamic programming over static xml files. Maybe good lsp/ide support will make managing a build system like this bearable?

Yes, IDE support in Mill is key. Without IntelliJ or VSCode, Mill would not be nearly as pleasant to use as it is today.

Mill and Maven both let you declare goals for what you want to do. One does it in XML and one does it in typechecked code. While XML does work, doing things in code with typechecking and full IDE support turns out to be pretty nice as well!

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

#39

Post by philipwhiuk »

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…

The current version is 0.12.1.

What's required for v1.0?

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

#40

Post by lihaoyi »

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…

If you think gradle and maven are bad, you should try Mill! There is more to build tooling than gradle or maven, the field has evolved significantly since those tools launched 15-20 years ago, and Mill tries to do things better
Post reply on HN