Hacker News Reader

Comment by iamcalledrob | Hacker News Reader

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 either! - Build scripts written in a language that can be used for code too: Versioning hell when the compiler for the build system needs to be a different version to the compiler for the actual project code. See: Gradle and Kotlin

View on HN

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

I agree that Bazel did pretty well with Starlark, but the reason that’s sane is because it’s not Python, though the syntax is similar. It avoids getting into trouble with people using Python language features that would result in upgrade hell and annoy other programmers who aren’t Python experts.

(Though, debugging complicated Starlark code can still be difficult.)

So why not use Starlark? :)

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.

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

Starlark is great, but so is Scala. People underestimate how big the ecosystem is even for a niche language like Scala:

- Global publishing and distribution infrastructure

- IDE support in multiple IDEs

- A huge ecosystem of third party packages, both Scala and Java

- An excellent Scala standard library and Java standard library

- Good performance.

- Tooling! Jprofiler is great. Others use Yourkit or JFR.

- Mill leans havily on Scala's FP/OO hybrid style with types, while starlark provides none of that and is purely untyped procedural code

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

Greenspun's tenth rule.

There is basically no DSL. You simply write what a build needs, e.g. you write a function `collectCFiles()` that collects every file with extension `.c`. You then issue a command like `gcc ${collectCFiles()}`. And pretty much that’s it - you can use shell commands, or do anything in scala (or java or whathaveyou). You simply have your functions return either a value (e.g. a checksum) or a location, which is the only mill-specific logic. So your compileC() function will simply invoke your collectCFiles() function, and this invocation implicitly creates a dependency between these tasks. You have written literally the simplest way to describe your build logic. But in the background mill will cache your functions’ inputs outputs and parallelize those that need re-run, which is what a build tool should do.

The implementation may not be the theoretical best, but I think the idea is pretty much the perfect build system out there.

The first advantage the homepage lists is:

> Mill can build the same Java codebase 5-10x faster than Maven, or 2-4x faster than Gradle

Speed per se can be a good selling point (having to wait for slow builds is really annoying).

I can't really comment on anything else though as I just stumbled upon it here in HN ;)

The goal should be more like 50x faster than Gradle. Gradle is ludicrously slow (at least in every single Gradle project I’ve had to work with).

First invocation may be. Subsequent builds are very fast, unless someone decided to write random bullshit into the build scripts that execute at config time, making the config process impure.

I’m mostly thinking of Android projects. If I have time I’ll try some speed tests with a new basic project. But I don’t think I’ve even once done something in Android Studio and thought “huh, that was surprisingly fast”. Maybe some of the hot reloading stuff is okay (when it actually works).

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.

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)

Are we talking about Maven with its cache extension?

https://github.com/apache/maven-build-cache-extension

Because in my experience, this makes Maven very, very fast.

Reply on news.ycombinator.com