Hacker News Reader

Comment by kaba0 | Hacker News Reader

To be blunt, if anything it might be you who live in a closed bubble.

Builds that require ad-hoc functionality is the default. It’s extremely rare that everything fits nicely into “cargo build” or other single language build tools’ model. And while these often have escape hatches, at that point you have to write imperative code with no caching and parallelization that is literally the job of a build tool.

View on HN

I've been doing jvm apps for almost 20yrs... What builds need to do and what people made the builds do are completely different things. I don't remember a single project I was involved in that could not had had a simpler build...

True. In our example we didn’t have to generate online help and pdf manuals from the same asciidoctor sources. But when we chose to, we really needed the customization that cradle offered.

> It’s extremely rare that everything fits nicely into “cargo build”

161538 crates do not agree with you ;)

Which are mostly small, isolated library code, whose purpose is to be easily incorporated into larger programs. That’s the 90% easy path of build tools.

What about a large project built over 6 years by 50 people, and that has to use some obscure technology to communicate with company A, and another one that has an idiotic build step?

> Which are mostly small, isolated library code, whose purpose is to be easily incorporated into larger programs.

Which is how software should be generally made - from small and simple things, not from huge behemoths that contain the kitchen sink and brew coffee.

The apps are also built using cargo build.

For your outlandish use cases you can use Bazel.

Reply on news.ycombinator.com