The place to start is probably build systems a la carte. The primary difference is that Nix has suspending scheduling and deep tracing builds and Bazel has restarting scheduling and tracing builds.
The more relevant difference is the tracing, Bazel will only hash one layer deep so it needs to traverse the whole dependency dag to confirm that all dependencies are in the proper state.. while Nix optimizes by hashing all dependencies, so it is quick to know what needs to be rebuilt, but in return it needs to rebuild everything if a fundamental dependency is changed (i.e. rebuild all dependents even if the change doesn’t actually propagate and is “killed” somewhere - e.g. when there is no interface change then there is no need for the dependent to care about the update).
That’s at least how I understand it, I’m sure someone can correct me.
I was wondering about this, too; was surprised they considered Bazel+Nix, but not Nix independently.
My experience with Haskell and Nix has been that while it Nix deals well with caching dependency artifacts, you have to switch back to cabal or similar for the main project if you want any kind of caching of partial builds, incremental rebuild etc. Do you have a good solution there?
I’ve heard good things about Bazel, though right now my company is using nix for our build.
Does anyone know of a good comparison among Bazel, Nix, and other caching build systems?
The place to start is probably build systems a la carte. The primary difference is that Nix has suspending scheduling and deep tracing builds and Bazel has restarting scheduling and tracing builds.
The more relevant difference is the tracing, Bazel will only hash one layer deep so it needs to traverse the whole dependency dag to confirm that all dependencies are in the proper state.. while Nix optimizes by hashing all dependencies, so it is quick to know what needs to be rebuilt, but in return it needs to rebuild everything if a fundamental dependency is changed (i.e. rebuild all dependents even if the change doesn’t actually propagate and is “killed” somewhere - e.g. when there is no interface change then there is no need for the dependent to care about the update).
That’s at least how I understand it, I’m sure someone can correct me.
Yep, that seems correct (having worked w/ both) as a good summary.
I was wondering about this, too; was surprised they considered Bazel+Nix, but not Nix independently.
My experience with Haskell and Nix has been that while it Nix deals well with caching dependency artifacts, you have to switch back to cabal or similar for the main project if you want any kind of caching of partial builds, incremental rebuild etc. Do you have a good solution there?
[Comment removed by author]