There are a few reasons why people use Blaze-inspired build systems (in addition to Bazel there are Buck and Buck2, Pants, Please, and others). Such build systems are sometimes called “action-cached”, which refers to a design in which the build is expressed in a way to maximize opportunities for caching based on the inputs to an action rather than the mtime like Make.
One big reason is speed: aggressively cached builds are generally much faster. This is very similar to how Turbo gets used in the JS/TS ecosystem, but for many more programming languages. Bazel in particular is very well-supported for transparent remote caching, so your build will often get faster rather than slower as the number of contributors goes up.
Another common reason is that in the presence of more than one or two programming languages, and particularly if one language is furnishing libraries to another, having a unified build rapidly makes it much more manageable to learn one build tool well rather than learn multiple build tools and some orchestration glue on top. A common example here would be the C/C++ extensions that are all but ubiquitous in high-performance numeric and scientific Python applications.
A third example is that C/C++ don’t really have a package manager in the sense that Rust has Cargo. CMake is probably the most popular these days, but it has its own problems and doesn’t interoperate well with other languages.
People seem to like making fun of Bazel et al, and I suppose that’s understandable: it’s difficult to learn and not worth learning until you have the problems it addresses. Add in the default animus for all things FAANG and it’s kind of an easy point to score. But this tendency is what Andre Alexandrescu calls “aggressively intermediate”, when senior people criticize Bazel they do so with valid concrete arguments (and such exist), it’s never “FAANG cargo cult” FUD.
Turbo is popular in the front end for a reason, an imprecise but still useful analogy is that Bazel is “Turbo for backend”.
Comments
There are a few reasons why people use Blaze-inspired build systems (in addition to Bazel there are Buck and Buck2, Pants, Please, and others). Such build systems are sometimes called “action-cached”, which refers to a design in which the build is expressed in a way to maximize opportunities for caching based on the inputs to an action rather than the mtime like Make.
One big reason is speed: aggressively cached builds are generally much faster. This is very similar to how Turbo gets used in the JS/TS ecosystem, but for many more programming languages. Bazel in particular is very well-supported for transparent remote caching, so your build will often get faster rather than slower as the number of contributors goes up.
Another common reason is that in the presence of more than one or two programming languages, and particularly if one language is furnishing libraries to another, having a unified build rapidly makes it much more manageable to learn one build tool well rather than learn multiple build tools and some orchestration glue on top. A common example here would be the C/C++ extensions that are all but ubiquitous in high-performance numeric and scientific Python applications.
A third example is that C/C++ don’t really have a package manager in the sense that Rust has Cargo. CMake is probably the most popular these days, but it has its own problems and doesn’t interoperate well with other languages.
People seem to like making fun of Bazel et al, and I suppose that’s understandable: it’s difficult to learn and not worth learning until you have the problems it addresses. Add in the default animus for all things FAANG and it’s kind of an easy point to score. But this tendency is what Andre Alexandrescu calls “aggressively intermediate”, when senior people criticize Bazel they do so with valid concrete arguments (and such exist), it’s never “FAANG cargo cult” FUD.
Turbo is popular in the front end for a reason, an imprecise but still useful analogy is that Bazel is “Turbo for backend”.