Get Nix onto your machine correctly the first time. We compare the upstream and Determinate Systems installers, explain single-user versus multi-user setups, and show how to uninstall cleanly — so you can start experimenting knowing you can always back out without leaving a mess.

Your first taste of the Nix superpower: run any of 100,000+ packages without installing them. With nix run and nix shell you reach for a tool, use it, and let it vanish — no global clutter, no version conflicts, nothing to clean up afterwards.

When you do want a tool to stick around, nix profile is how. Learn to install, list, upgrade, and roll back the packages in your user profile — package management that never strands you on a broken upgrade, because the previous generation is always one command away.

Nix keeps every version it has ever built — a feature, right up until your disk fills up. Learn the single command that safely reclaims that space on day one, so storage never becomes the reason you stop exploring. (We return to how garbage collection decides what's safe later in the course.)

Spend ten minutes here and the next two hours of language learning go three times faster. We set up nixfmt for formatting and nixd as your language server — autocomplete, jump-to-definition, and inline errors — in VS Code, Neovim, Emacs, or JetBrains. The viewers who skip this step always come back to it, usually after some avoidable frustration.

Think of Nix as "JSON with functions". In a couple of minutes you'll see why a real language beats static templates for configuration — and why that single design decision is what makes everything else in Nix possible. The natural answer to "why not just YAML?"

Meet the Nix REPL — the fastest way to learn the language and a genuine power tool. Watch it patch the hello program live to print a custom greeting, reload with :r, and drop you straight into a shell running the patched build. Three Nix superpowers — overrides, the REPL, and the store — on screen at once, plus the colon-commands (:b, :p, :doc) that make the REPL your daily workbench.

The complete tour of Nix syntax in one focused sitting: strings and indented strings (with the tricky ${} escapes), numbers, lists, attribute sets and inherit, functions and currying, let/with scoping and their pitfalls, import, and how to merge sets with // versus lib.recursiveUpdate. After this, nixpkgs source stops looking like a foreign alphabet and becomes something you can actually read.

Every language needs a way to ask "what is this value, really?" Learn builtins.trace, builtins.toJSON, and how to read a Nix stack trace without flinching — plus why there's no step debugger in Nix, and why you won't actually miss it.

This is the video that explains 90% of "huh, why didn't that fail?" moments. Through the famous 1/0 puzzle and weak head normal form, you'll finally get lazy evaluation — what it buys you for performance and debugging, and why Nix only ever computes what it truly needs.

The building blocks for everything that follows: head, tail, length, and writing your own recursive functions. We also explain why the syntax is the way it is — so it sticks in your head instead of feeling arbitrary — and set you up for your first hands-on exercises.

Hands-on: write a function that takes a list of numbers and returns their sum, using head, tail, and length. Ten minutes of real practice that stops you fighting the syntax for the rest of the course.

Hands-on: write takeN, a function that returns the first N elements of a list. Together with the sum exercise, this is what turns "I've seen the syntax" into "I can write it" — and it pays off for the rest of the week.

The functions you'll reach for every single day: map, filter, foldl', listToAttrs, mapAttrs — and exactly where they live in builtins versus pkgs.lib. A single guided tour through lib/lists.nix (plus noogle.dev for finding the rest) saves more hours than the whole rest of this section combined.

How to bring in nixpkgs the right way: import <nixpkgs> { } versus pinning a specific commit for true reproducibility, plus config.allowUnfree and permittedInsecurePackages for the real-world cases the quick tutorials quietly skip.

What's wrong with installing toolchains system-wide — and why Docker's sealed box fights you the moment you want to develop inside it. The case for per-project environments that are reproducible, disposable, and identical for everyone on the team.

The quickest concrete win in Nix: a few lines of shell.nix, and your project has exactly the compilers, interpreters, and CLI tools it needs — on every machine, without installing anything globally. If one video sells you on dev shells, it's this one.

Your package definition already knows its build dependencies — so stop repeating them. Learn how to derive the dev shell directly from the package, so the environment you develop in is guaranteed to match the environment you build in.

Developers want more than the build needs: formatters, linters, debuggers, language servers. Learn how to layer these extras on top of the package's own dependencies — one source of truth, no duplicated lists to drift out of sync.

The modern, flake-based counterpart to nix-shell: how nix develop works, what a devShell output looks like, and honest guidance on when to reach for which of the two worlds.

Automatic per-directory environment activation: cd into the project and the right tools are simply there — leave, and they're gone. This is the feature that converts skeptics for real.

A three-minute live build of hello: watch the sandbox get set up, the builder run, and the output land in the store. Along the way we separate evaluation from realisation — .nix → .drv → /nix/store/... — and plant the questions the rest of this section answers.

A tiny derivation tries to curl the internet, read /etc/passwd, and use tools it never declared as inputs — and every single attempt fails. This is the mechanism that makes "works on my machine" structurally impossible.

We run nix derivation show on a derivation written by hand with builtins.derivation and find… no magic at all: a list of store paths to provide, environment variables, a builder, and args — mapping 1:1 onto the execve(2) system call. Every Nix abstraction you'll meet later is sugar on top of this.

Hands-on: write a builder shell script, fill $out, declare coreutils, gcc, and gnumake as inputs, inspect the resulting .drv, and install your creation with nix profile install. This is the exercise that crystallises everything you just watched.

Walk through a real /nix/store/<hash>-<name> path and trace its dependencies with nix-store --query --tree. Runtime versus build-time dependencies, and the neat trick behind it all: Nix scans output binaries for store-path references to detect what a program truly needs at runtime.

Our minimal mini-hello recipe has a flaw: it rebuilds even when nothing meaningful changed. We dig into why that is and fix it — a first taste of how Nix decides what needs rebuilding and how to keep your builds cached.

wget, tar, ./configure, make, make check, make install — the ritual every Unix project has followed for decades. The GNU project structured it into phases long before Nix existed, and that structure is exactly what stdenv.mkDerivation automates. Recognise the dance and mkDerivation stops looking like something you have to memorise.

Build GNU hello in three lines. You supply name and src, the default phases do the rest — this is the moment packaging turns from writing a builder script by hand into declaring what you have and letting stdenv drive.

Bash, a C compiler, coreutils, patch, make, the whole GNU toolchain — the batteries in mkDerivation's batteries-included. We take inventory of what you get for free, then declare everything else with buildInputs and its siblings.

unpack, patch, configure, build, check, install, fixup: each one a hook with a sensible default, each one yours to override or extend with pre* and post*. Plus the escape hatches — dontUnpack, dontBuild, doCheck — for the projects that refuse to follow the script.

Hands-on: write configurePhase, buildPhase, checkPhase, and installPhase yourself, then add a patches = [ ./… ]; entry that changes the greeting. By the end you've packaged a real GNU project from source — with a patch you wrote.

Builds fail — learn to fix them without frustration. nix-build --keep-failed to inspect the wreckage, NIX_DEBUG when you need more detail, and pkgs.breakpointHook (Linux only) to drop into an interactive shell inside the failed build. Plus a taxonomy of the common errors and the first thing to check for each.

import <nixpkgs> { } means something different on every computer — and that quietly undoes the reproducibility you came for. Learn to pin your code without flakes, and pick up how downloading pinned content works in Nix generally along the way.

fetchurl, fetchzip, fetchpatch, fetchgit, fetchFromGitHub — and the question everyone asks eventually: why does the hash appear twice? Meet the fixed-output derivation, plus TOFU versus computing the hash up front with nix hash file or nix-prefetch-git.

A quick tour of buildPythonPackage, buildGoModule, and buildRustPackage with vendorHash/cargoLock, plus crane for Rust. You don't need to memorise any of them — the point is that once mkDerivation has clicked, you can read all of them.

runCommand for one-off transformations, symlinkJoin for assembling $PATH-style directories, and writeShellApplication for shipping team scripts with shellcheck running at build time — the most rock-solid way to distribute a shell script you'll ever use.