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

91–100 of 168 posts

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

#91

Post by dkarl »

beeboobaa3 wrote: post #70
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…

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, which in my experience causes way more pain than custom code in a build file. Custom logic in Maven means building and publishing an extension; it can't be local to the project. You may encounter projects that depend on extensions from long-lost open source projects, or long-lost internal projects. On one occasion, I was lucky to find a source jar for the extension in the Maven repository. It can be a nightmare.

The same could happen with Gradle, since a build can depend on arbitrary libraries, but I never saw it in the wild. People depended on major open-source extensions and added their own custom code inside the build.

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

#92

Post by imtringued »

lihaoyi wrote: post #24
cryptos wrote: post #13

The comparision with Gradle is not up to date. There is stated that you would end up in an untyped mess of Groovy build files, but statically typed Kotlin files are the default for quite some time now in Gradle! https://mill-build.org/mill/0.12.1/comparisons/gradle.html

Author here. Unfortunately this is because my own experience with Gradle is not up to date; I've only lived in the Gradle Groovy world! If anyone is interested in helping out, I have a 1500USD bounty on porting a gradle.kts build to Mill, so we can do a fair up-to-date comparison https://github.com/com-lihaoyi/mill/issues/3670

You can maintain your competitive advantage over gradle by not constantly breaking backwards compatiblity, by the way.

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

#93

Post by brabel »

cryptos wrote: post #13

The comparision with Gradle is not up to date. There is stated that you would end up in an untyped mess of Groovy build files, but statically typed Kotlin files are the default for quite some time now in Gradle! https://mill-build.org/mill/0.12.1/comparisons/gradle.html

I never got why people thought Kotlin would help Gradle. It absolutely doesn't.

Groovy was never the problem (Groovy has types, always had, you could use them if you wanted).

Think about it: what do you do with a build tool? You write a little recipe, then you run it. Does that remind something? Yes, it reminds scripts, like bash scripts you run all the time in your terminal. And why are scripts almost universally written without types... and no typed alternative, of which there are many, has caught on? Because if you're just going to modify a script and immediately run it, while keeping it short enough so you can know what it does without reading a book, how does adding types help you? Quite to the contrary, scripts (including build scripts) should be small, and having types all over the place make it far more verbose than it should be, likely pushing it out of your comfortable local memory in your brain, at which point you need something akin to a "real" programming language and a compiled program, not a script. Larger programs benefit from types because you don't just run the program, make changes, and run them again, like you do with scripts. You write them, test them, compile them, package them and finally you distribute them to your users who hopefully only need to configure them, not modify their internals. If your build is that complex, that's exactly what you should be doing instead of trying to shoehorn types into your scripts and expecting them to look like real programs.

Also, the Kotlin DSL just doesn't assist in the most problematic aspect of Gradle: its total lack of discoverability. Try doing something on your Kotlin Gradle file using a plugin you're not familiar with (which is all of them for most of us). It's completely impossible unless you know the DSL of the plugin, just like it was the case with Groovy... Once you know the DSL, it's fairly easy, but even in Groovy you will get auto-completion once you've got to the DSL "entry point", no need for Kotlin. I've been saying this since before they introduced the Kotlin DSL, and now i feel completely vindicated. I've never met anyone who told me "Gradle is so much easier now with Kotlin". But it did mess up plugins I wrote in Kotlin as now Gradle has a dependency on a very particular version of the Kotlin compiler, and God help you if your plugin was written with a different version in mind.

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

#94

Post by imtringued »

iamcalledrob wrote: post #5
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'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'm in JVM land. I spend very little time dealing with the build system. It is actually insane how well it works.

Also, why does it matter how long it takes to publish a library for the first time? It sounds like a non-issue to me. I have written dozens of libraries and published them to a local artifactory instance because it simply doesn't matter if your company specific code is accessible to the world or not.

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

#95

Post by carrotsalad »

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…

> It's intended as a replacement for _scala_ builds. Having a build definition in the native language [...] makes task customization easier for the maintainer

Totally agree! But the title of the post says "Mill: A fast JVM build tool for Java and Scala" :) - it certainly looks like better tool for the Scala community.

For projects that are primarily building Java sources, it'd be nice to have a build system that uses Java code to describe the build. I don't think this exists at the moment.

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

#96

Post by ackfoobar »

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

> end up implementing their own half-baked programming language interpreter inside of their XML

Greenspun's tenth rule.

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

#97

Post by mrudolph22 »

vamega wrote: post #78
mrudolph22 wrote: post #68

Earlier quoted context omitted.

Just wanted to mention that there are much better config languages than Starlark by now: CUE, Pkl, etc.

Why do you call these other languages “better”? They’re different, but I’m not sure why either of the one’s you mentioned would be better for this use case.

Modern config languages offer strong validation and advanced IDE support, which is essential for a great user experience.

https://pkl-lang.org/intellij/current/highlights.html

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

#98

Post by mrudolph22 »

skybrian wrote: post #75
mrudolph22 wrote: post #68

Earlier quoted context omitted.

Just wanted to mention that there are much better config languages than Starlark by now: CUE, Pkl, etc.

I was going to mention Cue, but I’ve only read about it, not used it, and couldn’t actually say whether it’s better.

I'm afraid that no current config language is an obvious fit for Mill. That's because Mill is fully reactive and doesn't distinguish between build configuration and execution by design.

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

#99

Post by crznp »

carrotsalad wrote: post #95
jackcviers3 wrote: post #83

Earlier quoted context omitted.

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…

> It's intended as a replacement for _scala_ builds. Having a build definition in the native language [...] makes task customization easier for the maintainer Totally agree! But the title of the post says "Mill: A fast JVM build tool for Java and Scala" :) - it certainly looks like better tool for the Scala community. For projects that are primarily building Java sources, it'd be nice to have a build system that uses…

One option is `bld`. They added IntelliJ support since I looked at it last, so that's nice.

https://github.com/rife2/bld

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

#100

Post by mike_hearn »

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.

Post reply on HN