2026-02-02, 14:25–14:50, B.1.036
Nix lets us define entire systems as pure functions - deterministic, reproducible, and immutable.
Once evaluated, though, these functions produce fixed values: snapshots in time of the desired state.
Functional Reactive Programming (FRP), as implemented in mgmt, extends this model.
In FRP, instead of yielding a fixed value, functions can return a dynamic signal: a value that evolves over time, responding to other changes in the system.
Reactive Nix explores how these two paradigms meet:
What if Nix's purely functional configurations could describe continuous systems - systems which stay declarative but react automatically as their dependencies change?
Nix models derivations as pure mathematical functions:
system = f(configuration)
Each build yields a fixed, reproducible output.
But between builds that output is static - it cannot express time or change.
Functional Reactive Programming generalizes this idea:
system(t) = f(configuration, environment(t))
Here, the configuration remains pure, yet depends on signals that evolve continuously.
Despite its mathematical elegance, Nix as we use it today produces fixed values.
The world may change, but the configuration cannot react.
mgmt's FRP runtime provides a concrete realization of this idea: it observes the environment, reacts, and converges continuously to the declared state.
The rx.nix (Reactive Nix) project explores what happens when Nix's purely functional configuration model meets mgmt's continuous evaluation.
By treating Nix outputs as functions over time (not as fixed values), we can imagine systems that remain declarative, reproducible, and yet perpetually aligned with reality.
We will discuss:
- Current struggles of NixOS and the limits of static outputs
- Building intuition for Functional Reactive Programming
- How FRP can complement Nix
- Possibilities we gain by combining Nix with mgmt
DevOps Engineer at Dev Specialists GmbH