Hacker News Reader

Comment by bamazizi | Hacker News Reader

Curious as to why "if money is no object" regarding Bazel? Where are the hidden costs? Appreciate it if you could elaborate

I haven't used it before but i'm considering Bazel, Please.Build or Nix for our monorepo.

View on HN

The main thing to be aware of with Bazel is its sandboxing philosophy. Instead of using the files in place, it basically creates a copy of the relevant file structure for any given build (i.e. minus the files that might exist on a given folder but be irrelevant for a build). Because of this, it generally requires strict hermeticity guarantees from everything you're doing, so many things have to be done in a "Bazel way" (i.e. there are specific ways in which you're supposed to download dependencies and there are restrictions in terms of file creation in e.g. tests that might deal w/ I/O)

The way that Bazel approaches flexibility is by being programmable (via a Python-like language called Starlark). There are open source rulesets for various languages that you can use to get off the ground faster, but they are usually fairly opinionated, so if you want to deviate from the happy path, you're going to hit face first into a fairly steep learning curve about depsets, graphs, file/symlink permissions and the like.

Another "weakness" of Bazel is that it's not aware of ultra granular file-to-file dependencies out of the box (e.g. how Golang imports work vs Java's), so either you have to manage dependency graphs manually or you invest in wrapper tooling like gazelle to automate some of the BUILD file generation for you.

If you're doing something new it's pretty straightforward to start with bazel and do everything from the start 'the bazel way'. If you're pulling in an existing codebase and a lot of dependencies along with it, you could be spending a lot of time to make it work 'the bazel way'. There's a very narrow path that bazel forces you to be on--this is what makes it work so well but make it difficult to stray off that path.

The primary difference is that in Nix it's fairly easy to wrap arbitrary build systems, so you can inject third-party dependencies into your codebase without vendoring and adapting their build system (plus, through nixpkgs[0], the majority of all relevant software has already been wrapped).

In Bazel you have to do a lot of that work yourself. Google has essentially ~unlimited manpower to do this for the things in their third_party tree, but for any other size of organisation this is not the case and people resort to all sorts of ugly hacks.

Depending on your needs these different types of projects can also coexist with each other in Nix. To use an example from my work, we have a Nix-native build system for Go[1] and code using this[2] co-exists with code that just uses the standard Go build system[3]. Both methods end up being addressable on the same abstraction level, meaning that they both turn into equivalent build targets (you can see both in a full build[4] of our repo).

And for what it's worth, some of the things Bazel gets extremely right (such as having a straightforward mapping from code location to build target, universal build command) are pretty easy to do in Nix (see readTree[5], magrathea[6]).

[0]: https://github.com/NixOS/nixpkgs

[1]: https://code.tvl.fyi/about/nix/buildGo

[2]: https://cs.tvl.fyi/depot/-/blob/ops/besadii/default.nix

[3]: https://cs.tvl.fyi/depot/-/blob/third_party/gerrit-queue/def...

[4]: https://buildkite.com/tvl/depot/builds/13067

[5]: https://cs.tvl.fyi/depot/-/blob/nix/readTree/README.md

[6]: https://cs.tvl.fyi/depot@f0e6d3498d6c0f905977ea9432c311b6808...

Reply on news.ycombinator.com