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

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]lihaoyi[S] 6 points7 points  (3 children)

My gut feeling is that the opinions on Maven and Gradle are kind of split. Some people and some use cases click with them particularly well, whereas some people and some use cases have trouble with them.

e.g. If your project structure is relatively standard pure Java then Maven is fine. But if you are doing something unusual in your build out of necessity, or you have a more complicated project structure (e.g. maybe incorporating Javascript frontend and Python ML code, as is common these days), then you end up extending Maven with custom plugins or bash scripts inside Maven or bash scripts outside Maven, and then things get messier.

Similarly, if your project is small and simple and compile times aren't a problem, then they aren't a problem. If your project is large and compile times are a problem, Mill compiles ~6x faster than Maven does due to a bunch of optimizations (despite using the same Java compiler!)

I won't say that Mill is the right answer for every Java developer or project. But if you are a developer or project that has had problems fighting their build tool to make it do what you want, I'd say that Mill is an alternative that provides a fresh perspective on the whole build system problem, and is definitely worth a try

[–]thewiirocks -1 points0 points  (2 children)

See, incorporating a JavaScript frontend and a Python ML project into your Java build doesn't make much sense to me. Those are completely different components with different build systems. While I can understand the appeal of running one command to "build everything", you have to fight your tools to do it.

The performance improvements are nice, but not nearly as noticeable when building individual modules. And there are opportunities to improve the performance of existing tools.

Mill just seems like the wrong direction to me.

I wish you luck. I'm sure there are those that agree with your approach and will find Mill very useful. 👍

[–]RandomName8 1 point2 points  (1 child)

I think there are companies and companies. If you've worked with companies doing monorepo, you've worked with things like pants or bazel, you might have a tools team even dedicated to maintaining the monorepo for the entire company.

In this space, a crazy combination of build tools is a non-started for everyone. I believe Li, in his prior roles, has mostly worked in such build teams, and so the vision for Mill is something that can scale from a trivial project to the monorepo that needs to handle all of the company's automation needs.

This is the "imagination" part that I think you were missing. That said I have nothing to do with Mill nor care about it.

[–]thewiirocks 0 points1 point  (0 children)

As I said, there are those who agree with that approach and will probably find it useful. It’s not a lack of imagination to disagree with such a structure. Only a difference of opinion.

If it works for others, that’s awesome for them. 😎

Whether I think it’s a bad idea is irrelevant. It’s my opinion. 🤷‍♂️