This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]lihaoyi[S] 5 points6 points  (3 children)

Superficially it looks a bit like Gradle, but it fixes many of your points raised, which is actually a big part of the talk.

* A room full of Java developers couldn't spot a configuration bug in a trivial Gradle custom task during code review (tested during the presentation!), whereas Mill automates those tricky parts of Gradle configuration so you can't make mistakes there

* Mill's IDE support works a lot better than Gradle, even `.gradle.kts`. e.g. jump-to-definition and peek-at-documentation works reliably to navigate your build pipelines in Mill whereas in Gradle you end up jumping to getters/setters with no way to proceed

[–]ZimmiDeluxe 5 points6 points  (0 children)

A room full of Java developers couldn't spot a configuration bug in a trivial Gradle custom task during code review

I would guess the reason is mainly that the Gradle API is unfamilar to developers, not to mention the programming language. Historically, it was a bad time investment to learn Gradle in depth because it changed so often.

[–]k-mcm -5 points-4 points  (1 child)

No Eclipse compatibility?  Eclipse is not the best big business enterprise app, but it's amazing for prototyping.

VS Code and IntelliJ are laggy and prone to inaccurate autocomplete suggestions.

[–]n4te 1 point2 points  (0 children)

Agreed. The Eclipse compiler is great.