7 ms·

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: Crea

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

fabioz 2y ago
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 ;)
- iainmerrick 2y ago
  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).
  - kaba0 2y ago
    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.
    - iainmerrick 2y ago
      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).
- ktosobcy 2y ago
  AFAIR author made quite unfair comparison with simple compile vs full maven build (that executes a lot of additional stuff)
  - switchbak 2y ago
    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.
    - hocuspocus 2y ago
      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.
    - ktosobcy 2y ago
      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)
- speed_spread 2y ago
  Are we talking about Maven with its cache extension? https://github.com/apache/maven-build-cache-extension https://github.com/apache/maven-build-cache-extension Because in my experience, this makes Maven very, very fast.
kaba0 2y ago
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.
lihaoyi 2y ago
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/choosing-what-your-workflow-does/evaluate-expressions-in-workflows-and-actions https://docs.github.com/en/actions/writing-workflows/choosin... * CloudFormation Functions https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference.html https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGui... * Helm Chart Templates https://helm.sh/docs/chart_best_practices/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
- skybrian 2y ago
  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? :)
  - mrudolph22 2y ago
    Just wanted to mention that there are much better config languages than Starlark by now: CUE, Pkl, etc.
    - skybrian 2y ago
      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.
deleted 2y ago
[deleted]

fabioz 2y ago

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 ;)

iainmerrick 2y ago
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).
- kaba0 2y ago
  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.
  - iainmerrick 2y ago
    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).
ktosobcy 2y ago
AFAIR author made quite unfair comparison with simple compile vs full maven build (that executes a lot of additional stuff)
- switchbak 2y ago
  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.
  - hocuspocus 2y ago
    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.
  - ktosobcy 2y ago
    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)
speed_spread 2y ago
Are we talking about Maven with its cache extension? https://github.com/apache/maven-build-cache-extension https://github.com/apache/maven-build-cache-extension Because in my experience, this makes Maven very, very fast.

kaba0 2y ago

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.

lihaoyi 2y ago

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/choosing-what-your-workflow-does/evaluate-expressions-in-workflows-and-actions https://docs.github.com/en/actions/writing-workflows/choosin... * CloudFormation Functions https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference.html https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGui... * Helm Chart Templates https://helm.sh/docs/chart_best_practices/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

skybrian 2y ago
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? :)
- mrudolph22 2y ago
  Just wanted to mention that there are much better config languages than Starlark by now: CUE, Pkl, etc.
  - skybrian 2y ago
    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.

deleted 2y ago

[deleted]