// article 01 — what is nix?

What Nix Is: Building an Intuition

Nix is two things: a package manager and a programming language. The interesting part is how tightly those two are connected — and that's the subject of this article.


The problem Nix solves

Imagine writing down, in a notebook, the exact steps you took to install a piece of software: download this file, run this command, copy that folder here, edit this setting.

Hand that notebook to a friend with a different computer. Will it work?

Maybe. Maybe not. Their computer might already have a slightly different version of some tool your steps depend on, and your instructions could silently use that version instead — breaking something in a way that's hard to trace. Or your notebook says "download the latest version of X," and by the time your friend follows it, "latest" means something different than it did for you.

This is the classic "it works on my machine" problem. The root cause is always the same: instructions describe actions to take, and actions depend on the state of the machine they're taken on. Identical instructions, run on two different machines — or the same machine on two different days — can produce two different results.

Nix's core bet: stop writing instructions. Write descriptions. Describe, with total precision, exactly what you want to exist, and let a separate, mechanical process turn that description into reality — the same way, every time, on any machine.

Describing something vs. doing something. That separation is the whole shape of Nix.


To describe things precisely, you need a language for descriptions. That's what the Nix language is for. It's called a declarative language — its job is to describe a desired outcome, not to list steps for reaching it. One sentence captures the whole idea:

A Nix file is not a set of instructions to carry out. It is a mathematical expression that evaluates to a value — exactly like 2 + 2 evaluates to 4.

Most early confusion with Nix comes from quietly assuming Nix files are scripts — "download this, then run that, then copy this file." They aren't. Once this idea is solid, things like system configuration, packages, and flakes stop looking like separate mysteries and start looking like the same idea in different clothes.

The calculator analogy

Type 2 + 2 into a calculator and it shows 4. A few things about that are easy to take for granted:

  • The calculator doesn't affect anything outside itself. It doesn't remember yesterday's calculation, and it doesn't behave differently depending on the time of day or which calculator you're holding.
  • Given the same expression, every calculator on Earth gives the same answer. Always. No ambiguity, no "it depends."
  • Bigger expressions are built from smaller ones: (2 + 2) * 3 uses the result of 2 + 2 as a piece of a larger calculation. It doesn't matter how deeply nested the expression is — it just evaluates, piece by piece, down to one final value.

This property — the same input always produces the same output, with no side effects — has a name in computer science: purity. A calculator is a pure system. It never surprises you based on hidden state.

The Nix language is a calculator. A far more elaborate one — it can hold text, true/false values, lists, and richly structured records, not just numbers — but the core behavior is identical: you write an expression, Nix evaluates it, you get a value back. Always the same value, for the same expression, on any machine, at any time.

Try it yourself

If you have Nix installed, you can open a tool called nix repl (REPL stands for "Read-Eval-Print Loop" — it reads what you type, evaluates it, and prints the result, in a loop). It behaves exactly like a calculator:

nix-repl> 2 + 2
4

nix-repl> (2 + 2) * 3
12

nix-repl> "hello " + "world"
"hello world"

Nothing was installed, downloaded, or written to disk. You typed an expression and got back a value. That's evaluation, in its purest form.

Here's where it starts to feel like magic, and it's really the entire subject of this series: values in Nix can be far more elaborate than numbers or text. A value can be a structured record describing an entire piece of software — its name, version, source location, and build steps. A value can even describe an entire computer's configuration: every program, every setting, every user account. We call this kind of value a blueprint.

Two separate worlds: evaluating vs. building

This is the payoff of the calculator analogy. There are two completely separate stages when you use Nix:

Stage 1 — Evaluation. Nix reads your expression (your file, or files linked together) and calculates a value from it. This is pure, like the calculator: no internet access, nothing installed, nothing decided based on whatever happens to already be on your machine. The output is a blueprint — a precise, structured description of something that could be built. Evaluation is typically fast, since it's only computing a value, not downloading or compiling anything.

Stage 2 — Building. A separate, much simpler process reads that blueprint and does the actual work: downloading source code, compiling it, placing files exactly where the blueprint says. This stage does touch your disk and network — but by the time it runs, nothing is left ambiguous. Every decision was already pinned down during evaluation. The builder isn't deciding anything; it's following the blueprint mechanically, the way a 3D printer follows a model file without needing to understand what the object is for.

This is exactly the fix for the notebook problem from the start of this article: instead of instructions that quietly depend on machine state, Nix pushes every decision into evaluation. By the time a blueprint exists, there's nothing left to decide — which is why the same blueprint builds the same result, on any machine, every time. This property has a name: reproducibility.

Quick recap

  • Traditional instructions describe actions, and actions depend on machine state — the root cause of "works on my machine."
  • Nix describes values. A Nix file is an expression, evaluated like 2 + 2: purely, deterministically, with no side effects.
  • Evaluating a Nix file produces one value. The values we care about are blueprints — precise descriptions of something to build.
  • Evaluation (calculating the blueprint) and building (mechanically following it) are two separate stages — one pure and safe, one that actually touches your disk.
  • The payoff: reproducibility, easy sharing, safe experimentation (evaluation can't break anything), and composability — the same "small pieces build bigger pieces" idea as (2 + 2) * 3.