// HACKER NEWS — CYBERSECURITY
A build graph that rolls dice
We are right around the corner from NixCon 2026. Another year where I sadly won’t be present.
I looked at the lineup and saw quite a few talks on dynamic derivations, along with some recent other posts on the topic such as cargo-dyndrv which had me thinking about revisting the topic since my earlier posts on the subject.
I wanted to better understand the implications of dynamic derivations and how they change the build graph. Originally, I was focused on how it could replace the lang2nix style of build graph generation, but I realized that the implications are much broader than that.
The graph does not need to be known up front. It can be defined as the build progresses. 🧐
Traditionally, Nix requires you to ask it to build anything and it will tell you exactly the steps it will take ahead of time as the “derivations” that comprise the build graph.
This is an important property of Nix. It is what makes it possible to reason about builds without running them by understanding what will be built.
Many Nix tools rely on this property via nix build --dry-run.
For instance, nix-diff tells you why two closures differ without building either.
In functional languages it’s very easy to get abstract and use fancy words like “applicative” and “monadic” to describe the difference between types of computation. The difference is subtle, but it is profound.
Nix traditionally was an “applicative” build system. Dynamic derivations make it a “monadic” build system. The difference is that in an applicative build system, the entire build graph is known up front, while in a monadic build system, the graph can be defined as the build progresses.11The paper Build Systems à la Carte is the defacto read on this topic.
One way to think about the difference is to look at the type signatures of the two operations that define them: