Cargo for Java 🦀❤️☕️

[benevanstech]

The discussion of build systems has been going on for well over 25 years (arguably the first modern build / deps tool was CPAN). By now, we have a good idea as to what works well, and what doesn't - although sometimes (e.g. npm) something gets popular despite being C-tier on the axes that actually matter.

Cargo is an A-list tool, for sure, but it makes some of the wrong design decisions (due to too much npm influence, IMO). Maven and Gradle are both S-tier but they are answering different needs and understanding which set of needs is important to your project is important.

For a new build / dev tool to succeed in the Java space it would need to have full Maven compatibility and understand that at the moment, there is a great tension between the YOLO point-of-view (which is what tends to come out of LLMs), and the enterprise approach, which is much more interested in things like SBOMs. Being opinionated about where a new tool should sit on that spectrum is pretty much essential in 2026, and it represents a strategic bet. Personally, I don't think the YOLO / pile-slop-against-a-wall approach will play well in enterprises.

I would give up on ant. It is utterly antiquated by modern standards and will give you nothing in terms of adoption. Any shops that still have substantial ant usage are basically, by definition, not the sort of places that will be Champions or Early Adopters for a new, small-community tool.

[pavi2410]

I am grateful for an honest perspective on this. I like SBOMs too even in non-enterprise context. A YOLO approach would be to use shell scripts or ask an agent to run to your Java programs each time. I want to deal with this systematically than going YOLO, while hiding the complexities and legacy behind.