Nix - Package Manager That Actually Works

I've been using Nix for 3 years now. First month was hell, now I can't go back to npm breaking my environment every week.

Nix is a functional package manager that stores everything in /nix/store with weird hash names like /nix/store/b6gvzjyb2pg0kjfwrjmg1vfhh54ad73z-firefox-33.1/. First time you see this, you think it's broken. It's not. This is how Nix prevents the "install something, break everything else" problem that plagues traditional package managers.

What Actually Makes It Different

Traditional imperative package managers are stateful - they run install scripts that modify your system state. Nix is functional - packages are immutable values that can't interfere with each other. Sounds academic, but it means you can:

• Install conflicting versions of the same library
• Roll back changes without reinstalling your OS
• Share exact development environments with teammates

We're on version 2.29 now (September 2025). NixOS 25.05 "Warbler" dropped in May and actually works great. The community actually gives a shit and keeps things moving.

Learning Curve Reality Check

Expect to be confused for 2-3 weeks. The Nix language is functional programming on hard mode, and the error messages are cryptic garbage that make you question your sanity. Documentation ranges from excellent to "figure it out yourself," usually when you need it most.

But once it finally clicks (and trust me, it will), you realize every other package manager is fundamentally broken and you can't go back. I now use Nix for:

• Dev environments: `nix-shell` gives me isolated environments that actually work consistently
• Production deployments: Same packages, same versions, no surprises
• Personal machines: Home Manager lets Nix manage my dotfiles and user packages

Real-World Gotchas

• First install downloads everything from source. Takes hours.
• Flakes are "experimental" but everyone uses them anyway
• Some software doesn't play nice with Nix's isolation model
• Learning resources are scattered across wikis, forums, and incomplete docs
• Binary caches sometimes fail, forcing source builds at the worst times

Companies like FlightAware, Shopify, and Tweag use Nix because it prevents "works on dev, crashes in prod" disasters. The isolation guarantees are worth the learning curve.

The Weird Store Directory That Makes Everything Work

Everything lives in /nix/store with paths like /nix/store/b6gvzjyb2pg0-firefox-120.0/. That hash isn't random - it's computed from:

• The package source code
• Every single dependency (recursively)
• Build flags and compiler versions
• Even the system architecture

Change anything - even a fucking comment in a dependency's source - and you get a completely different hash. Sounds insane, right? But this is exactly how Nix prevents "works on my machine" disasters.

I learned this the hard way when a one-line config change triggered rebuilding half my system from source. Took 4 hours. But that rebuild was identical to what anyone else would get with the same config.

Multi-User Setup (Less Pain Than Expected)

The daemon setup actually works well. Non-root users can install packages safely because builds run in isolated namespaces.

Your packages don't interfere with other users, but everyone shares the same store. So if your teammate already built something, you get it for free.

One gotcha: the build users (nixbld1, nixbld2, etc.) might confuse your monitoring tools.

The Functional Language (Prepare for Pain)

The Nix language looks simple but will fuck with your head if you're used to imperative languages:

## This looks innocent
firefox = callPackage ./firefox.nix { };

## Custom variant - this is where it gets weird
firefoxDev = firefox.override { 
  enableDebug = true;
  enableTests = true;
};

Everything is lazy-evaluated. Functions are pure (no side effects). The type system is... unique. Expect to spend a weekend just understanding how to read package definitions.

But the composability is powerful. You can create variants of packages without touching the original definitions.

Garbage Collection (Because Disk Space Isn't Free)

Nix eats disk space like crazy. After a few months, you'll have 50GB in /nix/store. Run `nix-collect-garbage -d` to clean up old generations.

Pro tip: `nix-collect-garbage --delete-older-than 30d` keeps recent stuff but nukes old builds. I run this weekly.

The garbage collector is smart - it only removes packages not referenced by any profile or running process. You literally can't break your system by running garbage collection, which is more than I can say for apt autoremove.

Development Environments That Actually Work

This is where Nix shines:

## Instant environment with specific versions
nix-shell -p nodejs-18_x python311 postgresql

## Project-specific environment
nix-shell  # reads shell.nix

The environment is perfectly isolated. Want Node 16 for one project and Node 18 for another? Just works. No more "hold on, let me reinstall Node and break three other projects" bullshit.

Flakes are even better but they're "experimental" (everyone uses them anyway):

{
  description = "Dev environment";
  inputs.nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";
  
  outputs = { nixpkgs, ... }: {
    devShells.x86_64-linux.default = 
      with nixpkgs.legacyPackages.x86_64-linux;
      mkShell {
        buildInputs = [ nodejs python3 postgresql ];
      };
  };
}

Add `direnv` and your environment activates automatically when you cd into the project.

Binary Cache (Why Nix Doesn't Always Build From Source)

The binary cache serves pre-built packages. Most of the time, you download binaries instead of compiling.

When it works, installs are fast. When it doesn't, enjoy building Firefox from source for 3 hours.

Cache hit rate is usually good for common packages. For weird custom stuff or if you modify anything, you're building from source.

Organizations run private caches for proprietary packages. Works well once you get the signing keys sorted out.