Comment by elric | Hacker News Reader

Comment by elric | Hacker News Reader

Parent Full thread

Reading these comments I'm always amused by how different people/teams have radically different needs & preferences, and how other people seem to be dismissive of those. "I don't need anything more than maven", "maven is too slow", "if it's not bootstrappable I don't want it", "there should only be one ultimate build tool", "I hate programming my build", etc.

These opinions are all valid, but only if they don't discount the validity of other strategies. There is no universal law of optimal build practices. There are cases where build performance is critical, and others where it's not. There are cases where configurability is important, and there are cases where it's not. Etc.

Personally, I love having a programmable build in plain Java, which is why I enjoy bld [1] these days. I'm probably the only person you'll ever meet who actually enjoyed using ant, so you're welcome to take my opinion with as much salt as you need to digest that.

[1] https://rife2.com/bld

Ant worked well because it was extremely _explicit_: You had to say what you wanted. This gave it a lot of flexibility. Unlike some other tools, you aren't running in front of a train trying to get it to stop and let you on. It doesn't go anywhere or do anything until you say so. The cost was pretty much zero defaults and a good bit of boilerplate.

I think a lot of people expected this from Gradle because the idea of "build as programming" seemed like it would give that stop-the-train-let-me-on-already ability. I don't know that it really worked out that way. Maven is all about running devs over, but it's faster than Gradle, which tries to start a daemon just like SBT.

Anyhow... this bld thing looks interesting, thanks...

Re: ant, make that two of us.

I use Gradle these days since IntelliJ doesn't work well with ant; but when I want to precisely control how a build is done and produce exactly the build products I want, I use ant. It's stable, it's well-documented, and I never need to guess what it's doing because it's doing what I told it to do.

I like the idea of an opinionated build tool; but I'm not happy with any of the ones I've tried.

> These opinions are all valid, but only if they don't discount the validity of other strategies.

I strongly agree with this as a general principle in nearly all technical discussions.

But also, if the discussion starts with declaring something is better than everything else (as the title here), then there's really no salvaging it anymore.

> There are cases where build performance is critical, *and others where it's not.*

I'm curious about those.

Often CI results are not put to use immediately, making build time irrelevant.

So you're okay with waiting a day to get "linter error, you've put this on a wrong line, dumbass"?

Who's talking about a day? The difference between a fast build tool and a slow tool is in the order of seconds, maybe minutes. Larger differences aren't down to the build tool but down to the codebase.

The difference between a tool that leverages incremental compilation effectively and one that almost always has to build from scratch (at least on CI) can be pretty huge and not "in the order of seconds".

That's more a CI issue than a build tool issue. Just about any (Java) build tool supports incremental compilation. But if your CI env doesn't have a place to cache those builds, it's not going to matter.

And even then it could be a matter of seconds on a smallish codebase. Nor everyone is building Google sized monorepos.

> Just about any (Java) build tool supports incremental compilation

I wish that were true. Maven is terrible at this, e.g. here's a bug report that's been open for 12 years: https://issues.apache.org/jira/browse/MCOMPILER-209

Even just doing things like "please predownload any dependencies in this one job and cache them, so they can be reused in these 5 other jobs" don't work reliably with maven because certain plugins like surefire download dependencies on the fly.

> Nor everyone is building Google sized monorepos.

Nor is everyone building "small-ish codebases". You don't have to be Google, I worked at a company with maybe 10 developers in total, but the codebase was over 10 years old and had a gazillion features (plus a lot of tech debt, obviously) and the build times were atrocious. It wasn't all maven's fault, of course (we had really badly written tests, for example), but the broken incremental compilation easily added 5-10 more minutes to each build.

Reply on news.ycombinator.com