The most useful way to watch Eelco Dolstra's 26-minute NixCon talk "Scaling Up Flakes," published on November 10, 2022, is to ignore the temptation to treat flakes as a nicer wrapper for default.nix and shell.nix files.[1] Dolstra states the real issue in the opening minute: one blocker to stabilizing flakes was that large repositories were being copied wholesale into the Nix store during evaluation, which made ordinary development painfully expensive.[1]

That framing still matters in 2026 because the current official documentation has not moved all the way to "problem solved." nix.dev still describes flakes as an experimental extension format with outstanding issues, while the reference manual defines a flake as a filesystem tree rooted by flake.nix, with dependencies pinned in a flake.lock graph.[2][3] The NixOS Wiki likewise still describes flakes as experimental and traces the feature back to the Nix 2.4 release line.[5] So this talk is valuable not as a victory lap, but as a precise explanation of one engineering boundary that had to move before flakes could scale beyond toy repos.

The thesis is narrower than "flakes are good." Dolstra's strongest point is that flakes only start to feel credible when hermetic evaluation stops requiring full tree materialization up front.[1][3] If purity means every one-character change produces another giant store copy, then purity becomes a tax. If source trees stay lazy until a path is actually demanded, the same purity goal starts looking operationally reasonable.

Image context: the cover uses a real OST photograph from the NixCon 2025 venue recap, not from Dolstra's 2022 session itself. It fits because this article is about the Nix conference circuit as the place where flake ergonomics, stabilization blockers, and scaling fixes get argued in public.[6]

In the opening four minutes, the problem is framed as a scaling bug rather than a usability complaint

Dolstra does not spend the early section selling outputs, templates, or developer-shell convenience.[1] He uses the time to name a failure mode. Around the 0:40 mark, he says flakes "don't work very well" for big repositories because Nix has a tendency to copy whole repositories into the store every time, and "that doesn't scale."[1] By roughly 3:00 to 4:15, he makes the cost concrete: a one-character edit can mean another multi-gigabyte copy, nix build .#hello on nixpkgs can take several seconds, and one local example had already consumed roughly 93 gigabytes on a compressed ZFS filesystem.[1]

That is why the talk ages better than many ecosystem presentations. It is not really about feature discovery. It is about where the cost of abstraction was landing. Flakes promised pinned inputs and a standardized project boundary, but the implementation detail underneath that promise was making large trees awkward to hack on.[1][3] The opening sequence is essentially a red-team memo against naive purity.

Around minute six, Dolstra explains why Nix copied whole trees in the first place

The middle of the talk gets stronger once he turns from pain to mechanism. Around 6:10 to 7:25, Dolstra says Nix had been good at reproducible builds but weaker at reproducible evaluation.[1] Before flakes, two developers could point at different NIX_PATH states and evaluate the same repository differently; untracked files or ../ references could also leak into evaluation.[1] Copying everything into the store was the simple way to wall off those impurities, even if the result was slow.

This is where the current manuals help the talk read less like improvisation and more like architecture. The nix flake reference explains that the lock file is a UTF-8 JSON graph isomorphic to the dependency graph of the root flake, and Nix generates it specifically to keep inputs pinned to exact revisions.[3] The nix flake lock manual then shows the operational side of that promise: inputs get updated deliberately, and specific edges can be rewritten with --override-input instead of letting ambient machine state decide the outcome.[4]

So the video's important move is not "let's loosen purity because big repos are annoying." It is "let's preserve hermetic evaluation without paying the old storage bill every time a developer touches the tree."[1][3][4]

Around 9:30, lazy trees change when materialization happens

The most revealing section starts around 9:26. Dolstra shows that fetchTree no longer needs to return an attribute set whose outPath is already a Nix-store path.[1] Instead, it can return what he calls a "magic value" that still knows its provenance, prints a useful source-style reference, and can represent a path inside the source tree without immediately copying the entire repository into the store.[1]

That distinction sounds small until he demonstrates the consequences. Around 10:13, he says explicitly that nothing gets copied to the Nix store unless you ask for it.[1] You can descend to something like README.md inside the tree and still remain in a lazy state; actual materialization only happens when the path must become a derivation input or otherwise be coerced into a store-facing representation.[1] Later, around 13:15 to 14:25, he extends the point by showing patched source trees and in-memory patch application through accessors rather than eager whole-tree duplication.[1]

This is the heart of the article's claim. Flakes are often discussed as a user-facing standardization layer, but the talk shows that their viability depends on a lower-level storage and evaluation contract. The official manual still describes flakes as filesystem trees with pinned inputs.[3] Dolstra's contribution here is to move the question from "what is a tree?" to "when does that tree have to become store data?" The answer is no longer "immediately."

The late section is about tradeoffs, not triumph

The talk would be much weaker if it ended with the lazy-tree demo. Instead, Dolstra spends the last substantive section on compatibility costs. Around 17:20 onward, he says flake lock files no longer carry a narHash for all inputs, because computing it would require reading the entire source tree, which is exactly the work the new design is trying to avoid.[1] Older Nix versions can therefore complain about a missing narHash, and some assumptions about store paths or local filesystem representations stop being safe type checks.[1]

That caution is why the current nix.dev wording still matters. As of March 28, 2026, the concept guide continues to call flakes experimental.[2] The NixOS Wiki says the same and dates the feature family to Nix 2.4 rather than presenting it as long-settled infrastructure.[5] Read together, the talk and the docs suggest a more realistic conclusion: lazy trees remove one major scaling blocker, but they do not erase the broader stabilization question.

If you replay the video now, watch where Dolstra spends his time. He gives only a short refresher on what flakes are. Most of the talk is about evaluation pollution, store-path timing, provenance, and what breaks when lock-file semantics change.[1] That emphasis is the lasting lesson. The hard part of making flakes usable was never the syntax of inputs and outputs. It was deciding where hermeticity gets enforced, and how much storage pain a team should have to pay in exchange.

Sources

1. NixCon, "Scaling Up Flakes," YouTube video, published November 10, 2022.
2. nix.dev, "Flakes" concept guide - current experimental status, dependency model, and follows semantics.
3. Nix Reference Manual, nix flake - filesystem-tree definition, dependency graph, and flake.lock structure.
4. Nix Reference Manual, nix flake lock - lock-file updates and --override-input behavior.
5. NixOS Wiki, "Flakes" - feature background, Nix 2.4 origin, and current experimental framing.
6. OST Eastern Switzerland University of Applied Sciences, "OST hosts NixCon 2025" - conference recap and photo source.