Nix handles the hard parts of a custom debugger
Original: Nix wrote half of my debugger
Why This Matters
Shows Nix's reproducibility model has untapped value well beyond package management.
Developer Farid Zakaria built Rewind VM, a deterministic VM for reproducing Nix build race conditions. He found that Nix's derivation model already solved the hardest debugger infrastructure problems—inputs, symbols, sources, and reproducibility.
Farid Zakaria's Rewind VM treats every Nix build as a pure function of its inputs, thread schedule included. The project grew quickly to include a source panel, stack frames, bookmarks, a Compare tab, thread lanes, and a 'Check from here' mode for pinpointing race conditions. Each time Zakaria anticipated a heavy implementation lift, he discovered Nix had already done the work.
A debugger needs exact program inputs, debug symbols, sources for every linked library, and a way to share all of that with another machine. That maps precisely to what a Nix derivation provides. Rewind wraps the closure into a read-only erofs image, boots the VM on it, and assigns each run an ID that's a hash of its inputs—mirroring Nix store path semantics.
To demonstrate, Zakaria used a classic two-thread bank account race: both threads read a balance, then write it back with a deposit, losing one update when a reschedule hits between read and store. On a 16-core machine the bug appeared in 396 of 1,000 runs. Rewind's `check` command perturbs the thread schedule across runs and narrows the failure to a single step—step 3237 in this case—in 11 seconds. The tool also validates NAR hashes against binary caches using only `.narinfo` fetches, keeping verification lightweight.