The build system should get out of the way to let us focus on our tasks, not be distracted by slow or unreliable builds, get fast feedback on changes, and let us know what’s in the software we’re shipping to our users. But, what does it take for a build system to be really fast and reliable? What does it take to know what’s in the software?
It requires aggressive parallelism and distributed caching to avoid redundant work between colleagues. And it requires complete knowledge and control of dependencies, build isolation to identify mistakes, and reproducible builds to verify results across machines and strengthen supply-chain security.
In this talk you will learn how [Google’s open source build system Bazel](https://bazel.build/) and the [purely functional package manager Nix](https://nixos.org/) join forces to provide fast, correct, and reproducible builds.
In this talk I will explain what we mean by correct builds, and will motivate why fast and correct builds are important and why you would care about reproducible and isolated builds. We will see how many common build systems fail to provide these desirable properties.
You will be introduced to [Google’s open source build system Bazel](https://bazel.build/) and will learn how it provides fast builds, how correctness and reproducibility is relevant, and how Bazel tries to ensure correctness. But, we will also see where Bazel falls short in ensuring correctness and reproducibility.
You will learn about the [purely functional package manager Nix](https://nixos.org/) and how it approaches correctness and build isolation. And we will see where Bazel has an advantage over Nix when it comes to providing fast feedback during development.
I will share how you can get the best of both worlds and combine Nix and Bazel and how you can get started with these tools. But, we will also touch on potential caveats and shortcomings of this approach.