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...