You’ve probably spent hours wrestling with Nix, trying to get your Docker builds to be perfectly reproducible. You think of it as a strict, no-nonsense package manager. But what if I told you that underneath that rigid exterior, Nix is secretly a fully functional state machine capable of running Super Mario 3?
Yeah, I didn’t believe it either. Until I saw this.
A developer recently did the unthinkable: they bypassed the entire “infrastructure” narrative and used Nix derivations to simulate gameplay in Super Mario 3. Instead of pressing buttons on a controller, you navigate the game by chaining attribute paths in your terminal. Want to move right, right, jump, and move right again? You just type:
nix build '.#level1.rightb.rightb.rightab.rightb'
And the output isn’t a compiled binary. It’s a screenshot of exactly where Mario lands after that sequence of inputs.
The tools we build for one purpose are often sleeping giants waiting for a completely different awakening.
This isn’t just a clever parlor trick. It shatters the boundary between infrastructure and application logic. Most developers view Nix as a build tool—a deterministic way to manage dependencies. But this example reveals something far more profound: Nix is effectively a Turing-complete Domain Specific Language (DSL) for modeling any stateful process.
Think about what a video game actually is. It’s a state machine. You have an initial state (Mario at the start of level 1). You have inputs (move right, jump). And you have deterministic transitions (the game engine computes the next frame based on the physics engine and the input).
Nix derivations work exactly the same way. An input goes through a deterministic process to produce a guaranteed output. When you map Mario’s position to a Nix attribute path, you’re just using the build system to compute the next state of the game.
When you treat a package manager like a state machine, the entire world becomes a derivation.
The tension here is beautiful. Nix is rigid, sterile, and aggressively deterministic. Video games are playful, interactive, and chaotic. Yet, they map to each other perfectly. The rigid determinism of Nix is exactly what makes it a perfect emulator for a retro game where the physics are entirely predictable.
Why does this matter to you? Because we get trapped in the mental models dictated by tool vendors. We think “Docker is for containers” and “Nix is for packages.” But the most innovative breakthroughs happen when we cross the streams. When we take a tool built for sterile infrastructure and use it to do something wildly creative, we uncover its true latent power.
The limits of our tools are only the limits of our imagination—and our willingness to look like idiots trying something absurd.
Next time you look at your build tools, don’t just see a pipeline. See a Turing-complete canvas. Maybe your CI/CD system is just one attribute path away from beating Bowser.
FAQ
Q: Isn't this just a useless parlor trick with no real-world value?
A: It’s a parlor trick that completely rewires how you understand functional programming. The value isn't in playing games; it's in realizing your build system can model any deterministic state transition.
Q: What's the practical implication for a working developer?
A: It means you stop viewing tools by their marketing labels. If Nix can emulate Mario, it can model complex infrastructure state transitions that go far beyond simple package management.
Q: What's the contrarian take?
A: Dedicated game engines and even traditional state machines are over-engineered. If your state transitions are deterministic, your CI/CD pipeline is already a better game engine than Unity.