Hacker News Reader

Comment by kadaj | Hacker News Reader

Software development is all about not re-inventing the wheel. Yet there are countless build systems, tons of pointless frameworks. I wonder developers have nothing else to do. Every company releases their own version of everything.

View on HN

My understand of Buck (and Pants) is that they are the result of ex-Google employees going to other companies (resp. Facebook, Twitter), realizing that Blaze was more or less the Right Way to do a build system (at least for their set of circumstances), and then being forced to re-implement the ideas from scratch (edit: or memory, or exfiltrated docs/code) because Blaze was not open source. Reusing extant software is great, but it requires that software to be available to you in the first place.

“Reimplementation from scratch” seems like a generous description of Buck. It was initially so like Blaze that I always assumed a xoogler exfiltrated at least the documentation of Blaze.

I really can't speak to that in any way, I was just trying to answer the OP's question as to why there are a number of--on face very similar--Bazel-style build systems. It certainly seems like a fair assumption, though.

Buck definitely looks familiar, having worked with e.g. bazel.

I remember that being a former Google intern.

Bazel is basically current Google employees doing the same thing due to how tightly Blaze is tied to Google infrastructure. Any open source projects or things that may one day be a separate business unit under alphabet rather than part of Google can't use Blaze, so they set out to make a version of Blaze that they can use.

What's the prior art here? Specifically,

- Support for thousands of related and unrelated codebases in the same repo, with a nuanced understanding of dependencies so that all "dirty" objects, and no others, are rebuilt/retested for each change.

- Hermetic builds to weed out undeclared dependencies.

- Support for remote build cache / remote build workers.

- Understanding of many unrelated languages.

I can't imagine GNU Make being reasonable in this kind of use case. What would you choose?

https://en.wikipedia.org/wiki/Not_invented_here

At a previous job we had the choice of buying a library for a couple grand from a field expert in said library or spinning one of our Senior engineers who clearly costs the company more than a few grand a year on rebuilding the same thing. Hundreds of thousands of dollars wasted (think about the management time, not just the employees own time) to build something in let's say a year, where said developer could of used the few thousand dollar library and done much more productive work to generate something of value.

Now they have to maintain a fork instead. What's worse is they likely wont know how it works in a year's time, imagine in a few years when they need him to update the library.

Sometimes it's better to buy a library than to waste resources reinventing someone else's tried and tested wheel.

Because nobody's done it right yet. Or if they have, they haven't marketed it right yet.

I, for one, applaud the effort. Maybe someday we can finally relegate CMake to the dustbin of history.

Reply on news.ycombinator.com