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

151–160 of 168 posts

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

#151

Post by pkolaczk »

rileymichael wrote: post #147
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.

How does that differ from `gradle init`?

Init and then what? The story of discovering and adding dependencies is still much worse. Nothing like cargo add/remove or crates.io where I can quickly search dependencies with their descriptions with standardized links to repos and documentation. Actually even Python is nicer in this regard with PyPi and pip install, even though virtual envs are pain.

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

#152

Post by pkolaczk »

kaba0 wrote: post #82
pkolaczk wrote: post #62

Earlier quoted context omitted.

> It’s extremely rare that everything fits nicely into “cargo build” 161538 crates do not agree with you ;)

Which are mostly small, isolated library code , whose purpose is to be easily incorporated into larger programs. That’s the 90% easy path of build tools. What about a large project built over 6 years by 50 people, and that has to use some obscure technology to communicate with company A, and another one that has an idiotic build step?

> Which are mostly small, isolated library code, whose purpose is to be easily incorporated into larger programs.

Which is how software should be generally made - from small and simple things, not from huge behemoths that contain the kitchen sink and brew coffee.

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

#153

Post by potamic »

lihaoyi wrote: post #30
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.?

Author here! `go build` and `go test` do work, at limited scale and complexity. In Scala there's Scala-CLI which is excellent. If they work for you, you probably aren't the target market for these build tools. Once you start layering on bash scripts, layering on make, layering on Python scripts, layering on manual steps written down in a readme.md somewhere, that's the time when you should consider a proper build too…

Thanks, the post actually answers my question on build requirements. It's a very good write up overall!

If your USP is to solve those layering cases, then why not target other ecosystems like golang/rust as well? Your design philosophy certainly seems to be language agnostic. By calling yourself a build tool for Java and Scala, it gives an impression that this is solving problems specific to those environments, and your adoption also indicates as such. Is it that these communities do not like to adopt such tools or is there something about the JVM ecosystem that tends towards having complex build requirements?

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

#154

Post by ktosobcy »

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.

Yeah... that's my experience with Scala all around - it's abysmally slow, especially if you use any sort of "metaprograming"... (one of the reasons I stay clear of the language)

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

#155

Post by cryptos »

brabel wrote: post #93
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 wr…

I disagree with the static vs. dynamic typing part. Modern statically typed languages (like Kotlin, Scala, Rust etc.) are concise and readable. In the case of the Groovy DSL for Gradle it was sometimes hard to get code right or to find a bug. Even IntelliJ struggled at times with this mess of a DSL. So, in my opinion Kotlin is definitely an improvement here!

However, I agree with your second part, the DSL as such. The syntax is arbitrary in many cases and just not easy to remember or to make sense of. It looks like a DSL for the sake of a DSL. Take a look at this example (https://docs.gradle.org/current/userguide/plugins.html):

    plugins {
        application                                     // by name
        java                                            // by name
        id("java")                                      // by id - recommended
        id("org.jetbrains.kotlin.jvm") version "1.9.0"  // by id - recommended
    }
Why are there two ways to reference a plug-in? Why is the version written without parenthesis? Why is version an infix operator? Why not something as simple and consistent as this:

    plugins {
       plugin(id="org.jetbrains.kotlin.jvm", version="1.9.0")
    }
How does the DSL help here? Is it more readable? Easier to lear or to remember?

Just look at Guice how nice a DSL can look like with pure Java:

    bind(CreditCardProcessor.class)
        .annotatedWith(PayPal.class)
        .to(PayPalCreditCardProcessor.class);
I'd really whish Java had build tools with better developer experience. I whish Mill the best luck!

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

#156

Post by lihaoyi »

potamic wrote: post #153
lihaoyi wrote: post #30

Earlier quoted context omitted.

Author here! `go build` and `go test` do work, at limited scale and complexity. In Scala there's Scala-CLI which is excellent. If they work for you, you probably aren't the target market for these build tools. Once you start layering on bash scripts, layering on make, layering on Python scripts, layering on manual steps written down in a readme.md somewhere, that's the time when you should consider a proper build too…

Thanks, the post actually answers my question on build requirements. It's a very good write up overall! If your USP is to solve those layering cases, then why not target other ecosystems like golang/rust as well? Your design philosophy certainly seems to be language agnostic. By calling yourself a build tool for Java and Scala, it gives an impression that this is solving problems specific to those environments, and y…

I called it a build tool for Java and Scala because that's what its good at right now. The software industry is hugely varied, so I can't target everything at once. In particular, this tool started off targeting 100% Scala, but branches out to Java since they share a lot of concepts (classfiles, jars, assemblies, maven central, etc.)

But you are right that it is not JVM specific! In the docs there is an example of adding Typescript module support, and an initial strawman implementation takes about 100 lines of code. I'm hoping others can extend Mill to places where I do not have the time and expertise

I also opened up a 500USD bounty to add a strawman Python example, so if anyone wants to try their hand at writing the 100 or so lines necessary, here's the link :) https://github.com/com-lihaoyi/mill/issues/3862

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

#157

Post by kimi »

brabel wrote: post #93
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 wr…

Yes the lack of discoverability, plus the unfamiliar syntax of Groovy, plus names changing between versions, I started with Gradle thinking it would be easier but in the end I'd love to go back to Ant. That was awful to write but at least you could understand it.

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

#158

Post by chikere232 »

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.

My problem with gradle is that they keep making breaking changes for low value things like naming of options, so I have to chase deprecation warnings, and can never rely on a distro supplied gradle version

Gradle devs, please get over yourself and stay backward compatible.

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

#159

Post by chikere232 »

kimi wrote: post #157
brabel wrote: post #93

Earlier quoted context omitted.

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

Yes the lack of discoverability, plus the unfamiliar syntax of Groovy, plus names changing between versions, I started with Gradle thinking it would be easier but in the end I'd love to go back to Ant. That was awful to write but at least you could understand it.

+1

I spent years copying essentially the same ant-file across projects, just changing dependencies and target names. It's not really rocket science and unless you're trying to be clever, most java projects can look pretty much the same from a build perspective

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

#160

Post by jitl »

kelnos wrote: post #146
jitl wrote: post #50

Earlier quoted context omitted.

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…

Name of the jar? `java build jar/foo` -> foo.jar, `java build src/dog` -> dog.jar.

Dependencies? It's okay to use a dependency list file for these - I guess I don't consider this config compared to the stuff I usually find in a Gradle or Maven file. The thing I'm alergic to is all the stuff that isn't a dependency list.

In Go, these go in a go.module file that's automatically updated by the build tooling, which runs instantly & has a cache you never need to think about. Go has the advantage of import paths being URLs that specify the dependency too, but I think my Go-For-Java tool would use reverse package import search from an online service to map eg com.foo.bar.something.Potato to the appropriate package "foo-bar" from Maven Central or whatever. Building that index seems like a trivial program to write for the average Java engineer.

The more I think about this "go for java" idea, the more I want to build it "in anger" just to see how off-base I am. Maybe I really am just going to re-implement or wrap sbt, mill, gradle, https://www.jbang.dev/ idk. It just feels like the experience could be an order of magnitude simpler as an end-user with some conventions strictly enforced by the tooling.

Post reply on HN