Nix – Death by a Thousand Cuts

Original Article ↗ Hacker News Discussion ↗

Enthusiasm for Nix and NixOS is tempered by widespread frustration with its complexity, fragmented tooling, and steep learning curve, especially on the desktop. Many users praise its declarative, reproducible configurations, powerful module system, and rollbacks—seeing it as exceptional for servers and development environments—but report that packaging edge cases, handling binary-only software, and navigating flakes or Home Manager can be brittle and poorly documented. A recurring theme is that the core ideas are strong and increasingly influential, yet the ecosystem still lacks clear “blessed” workflows and accessible ergonomics for non-experts.

Overall sentiment & use cases

  • Many describe a strong love/hate relationship: the core ideas (declarative config, reproducibility, rollbacks) are praised, while tooling, ergonomics, and docs are frequent pain points.
  • NixOS is widely seen as excellent for servers, CI, and dev environments; desktop suitability is heavily debated.
  • Several people keep Nix only for user‑space/dev (e.g., Home Manager or nix on macOS/Ubuntu) rather than as their main OS.

Desktop vs. server

  • On servers, users report major gains in stability, repeatability, and ease of upgrading/rollback.
  • On desktops/laptops, issues include Wi‑Fi/eduroam, NVIDIA/Wayland, webcam/sleep regressions, VS Code remote integration, and difficulty running generic Linux binaries.
  • Some daily‑drive NixOS happily and say they “can’t go back”; others tried and reverted to more conventional distros (Ubuntu, Arch, Fedora‑Atomic/Universal Blue).

Nix language, flakes, and workflows

  • The Nix language is widely seen as odd, under‑documented, and poorly tooled (weak LSP/“go to definition”, confusing module system).
  • Flakes are divisive: many consider them essential (pinning, pure eval, devShells, easy nix run), others note they’re still marked experimental, have UX issues, and overlap with non‑flake pinning solutions.
  • Lack of a clear, blessed “new user workflow” (system config layout, how to structure flakes, how to mix stable/unstable) is a recurring complaint.

Packaging, binaries, and compatibility

  • Nixpkgs’ breadth is praised, but:
    • Packaging complex or binary‑only software can be hard, especially when it assumes FHS paths or mutable config.
    • Tools like buildFHSenv, nix‑ld, steam‑run, distrobox, and AppImage helpers are common escape hatches.
  • Cross‑compilation and Raspberry Pi support work for some via remote builders and community projects, but are described as fragile or slow.

Docs, errors, and learning curve

  • Documentation is called fragmented, outdated in places, and light on end‑to‑end examples; many mention “too many ways to do the same thing.”
  • Error messages are often considered cryptic; LLMs are reported as unhelpful for non‑trivial Nix debugging.

Comparisons & philosophy

  • Some argue conventional distros + config management (Ansible‑like scripts, Btrfs snapshots, Timeshift) already solve most needs.
  • Others see Nix’s declarative, near‑stateless model as a qualitative upgrade over Dockerfiles, LTS distros, or ad‑hoc configs, despite the current “death by a thousand cuts.”