NixOS vs. Arch: Do You Want to Build the House, or Write the Blueprint?

I use Arch BTW

That's great! You definitely know how linux works under the hood. Arch linux is amazing for power users who want full control over their system. But what if you want full control over your system and reproducibility? That's where NixOS comes in.

First of all let's clear up something, Arch Linux and NixOS are not the same thing.

The Philosophical Difference

Arch Linux is a rolling release distribution that is known for its simplicity, minimalism, and flexibility. It is a great choice for users who want full control over their system and are comfortable with the command line.

But it's imperative. You have to manually configure everything. There's no "one command to rule them all."

Imperative programming is a programming paradigm that uses statements that change a program's state. You tell the computer how to do something, step by step. You could compare the philosophy to building a house by giving the construction workers step by step instructions. You have a general idea of what you want, but you act as a manager who tells them what to do, not what to build.

sudo pacman -Syu firefox neovim git

git config --global user.name "Felix Kjellberg"
git config --global user.email "felix@domain.com"

git config --list

NixOS thinks differently though. It's declarative.

Declarative programming is a programming paradigm that uses statements that describe the desired result. You tell the computer what you want, and it figures out how to do it. You could compare the philosophy to giving the construction workers a detailed blueprint of the house. They know exactly what to do, and you don't have to micromanage them. The blueprint in question is defined with the Nix language.

The Nix Language

The Nix language is a functional programming language that is used to configure NixOS. It is a domain-specific language that is used to describe the desired state of the system. It is a lazy language, which means that it does not evaluate expressions until they are needed. It is also a pure language, which means that it does not have any side effects.

In a developer's prespective it is comparable to a JSON file with extra features.

{ config, pkgs, ... }:

{
  # 1. DEFINE the state of software
  environment.systemPackages = with pkgs; [
    firefox
    neovim
    git
  ];

  # 2. DEFINE the state of configuration
  programs.git = {
    enable = true;
    config = {
      user.name = "Felix Kjellberg";
      user.email = "felix@domain.com";
    };
  };
}

It allows you to define what you need to modify, install, configure within your system and NixOS will build the parts for you.

These aren't parameters that NixOS created, it's actually exactly what is defined within the applications themselves. NixOS just provides a framework to configure them.

When you write programs.git.enable = true in Nix, you aren't just installing Git. You are triggering a Module.

• The Input: Your configuration.nix file.
• The Module: A specific .nix file in the Nixpkgs source tree (e.g., nixos/modules/programs/git.nix). This file contains logic that says: "If enable is true, write a text file to /etc/gitconfig."
• The Output: Nix generates a read-only text file inside the Nix Store and symlinks it to /etc/gitconfig.

NixOS is a ghostwriter. You give it bullet points (your options), and it writes the actual essay (the config file) for you. You never touch the final paper; you only edit the bullet points.

How do I know how to set it up?

You might be thinking, "That sounds great, but how do I exactly know how the Nixpkgs maintainers configure their software? What if something changes in the future?"

There are multiple ways you could find out

NixOS Wiki

The NixOS Wiki is a great resource for learning about NixOS. It has a lot of information about the different configuration options and how to use them. It's also a great place to find examples of how to configure your system.

Manual Pages

NixOS generates a comprehensive manual for every configuration option available in your system. Instead of searching online, you can access the documentation for every services.* or programs.* option directly from your terminal.

# View the manual for all NixOS configuration options
man configuration.nix

This manual is generated from the source code of the modules themselves, ensuring that the documentation is always in sync with your installed version. You can use standard man navigation (like / to search) to find exactly what an option does, its default value, and example usage.

Nix Repl

You can test out configurations in the Nix repl directly to ensure that they work as expected.

nix repl

nix-repl> map (x: x * 2) [1 2 3]

This will show you the exact output of the configuration you are about to apply to your system.

That might sound absolutely great but you might think it's a lot of work to switch to NixOS. And you're right, it is. But no one said you should switch to NixOS. You can use the Nix package manager on Arch Linux too!

The Nix package manager

Here's the plot twist: The Nix package manager is not exclusive to NixOS. It runs on any Linux distribution (Arch, Ubuntu, Fedora, you name it) and even on macOS. You can keep your beloved Arch install, your carefully tuned pacman.conf, your AUR helpers, and still get the superpowers of Nix where it matters.

Here's all the things you can do with Nix wherever you can get Nix installed

Installing Nix on any *nix system

The recommended way to install Nix is through the official installer. It sets up the Nix store at /nix and configures your shell automatically.

# The official Nix installer (multi-user mode recommended)
sh <(curl -L https://nixos.org/nix/install) --daemon

That's it. You now have the Nix package manager running alongside pacman. They don't conflict, pacman manages your system packages, and nix manages its own isolated store. Two package managers, zero drama.

Temporary dev environments with nix-shell

This is where Nix really shines on Arch. Instead of polluting your system with project-specific dependencies, you can spin up a temporary shell with exactly what you need.

nix-shell -p nodejs_20 python3

node --version  # v20.x.x
python --version  # Python 3.x.x

exit

This is something pacman or most package managers simply cannot do. You'd have to install packages globally, deal with version conflicts, or reach for containerization. With Nix, you get disposable, reproducible environments in seconds.

Persistent user-level packages with nix-env

If you want to install packages that persist across sessions but are still isolated from your system, nix-env is your tool.

nix-env -iA nixpkgs.ripgrep nixpkgs.fd nixpkgs.bat

nix-env -q

nix-env -e ripgrep

nix-env --rollback

Think of this as a user-level package manager that sits on top of pacman. Your system stays clean, and you get rollbacks for free.

Flakes: reproducible project environments

Flakes are the modern way to define reproducible environments. Instead of running ad-hoc nix-shell commands, you define a flake.nix at the root of your project. Anyone who clones the repo gets the exact same environment. flake.lock pins the exact versions of all dependencies, ensuring that the environment is reproducible across machines.

{
  description = "My project dev environment";

  inputs.nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";

  outputs = { self, nixpkgs }:
    let
      pkgs = nixpkgs.legacyPackages.x86_64-linux;
    in {
      devShells.x86_64-linux.default = pkgs.mkShell {
        buildInputs = with pkgs; [
          nodejs_20
          pnpm
          python3
          rustc
          cargo
        ];

        shellHook = ''
          echo "Dev environment loaded."
        '';
      };
    };
}

# Enter the dev environment defined by the flake
nix develop

# Or run it directly from a remote repo
nix develop github:owner/repo

This means your project's dependencies are version-pinned and reproducible across machines. A teammate on Fedora, a CI server on Ubuntu, and you on Arch. Everyone gets the exact same toolchain.

Home Manager: declarative dotfiles

Here's where it gets interesting. You don't need NixOS to manage your dotfiles declaratively. Home Manager lets you use the Nix language to configure your user environment on any system.

{ config, pkgs, ... }:

{
  # Packages to install in your user profile
  home.packages = with pkgs; [
    neovim
    tmux
    lazygit
    starship
  ];

  # Declaratively configure Git using the Nix language
  programs.git = {
    enable = true;
    userName = "Felix Kjellberg";
    userEmail = "felix@domain.com";
    extraConfig = {
      init.defaultBranch = "main";
      pull.rebase = true;
    };
  };

  # Declaratively configure your shell
  programs.zsh = {
    enable = true;
    autosuggestion.enable = true;
    syntaxHighlighting.enable = true;
    shellAliases = {
      ll = "ls -la";
      dev = "nix develop";
    };
  };

  # Import your existing dotfiles directly
  xdg.configFile = {
    "nvim/init.lua".source = ./config/nvim/init.lua;
    "tmux/tmux.conf".source = ./config/tmux/tmux.conf;
    "starship.toml".source = ./config/starship.toml;
  };
}

# Apply your home configuration
home-manager switch

You're running Arch. Your system is managed by pacman. But your user environment (your shell, your editor config, your Git settings) is fully declarative and reproducible. If you ever nuke your home directory or set up a new machine, one command brings everything back.

The Best of Both Worlds

This is the real takeaway. You don't have to choose between Arch and Nix. You can have:

• Arch's philosophy: A minimal, rolling-release system you built from scratch, managed imperatively with pacman.
• Nix's superpowers: Reproducible dev environments, declarative dotfiles, and rollback-capable package management, all running in userspace.

The Nix package manager isn't a replacement for pacman. It's a complement. Use pacman for your system (kernel, drivers, display server), and use Nix for everything that benefits from reproducibility (dev tools, project dependencies, dotfiles).

You built the house with Arch. Now you can write blueprints for the furniture.

Takeaway: Should you use NixOS?

Who is NixOS and Arch Linux even tailored for? Both seem powerful for what they are, but they are tailored for different purposes.

Arch linux

The reason people choose Arch is because it allows you to build your system from the ground up. But it's tailored for devops, not developers.

Arch Linux let's you focus on the system, not the development. It's a great distribution for people who want to learn about Linux and how it works. But it's not a distribution for people who want to focus on their development or who think in the declarative programming paradigm.

It's perfect for devops engineers, system administrators, and anyone who wants to learn about Linux. these people need to learn how the linux internal system works under the hood because they are responsible for maintaining and troubleshooting Ubuntu, RHEL, or other linux distributions in production. Until NixOS gets accepted as a mainstream distribution, Arch Linux will remain the best for those people.

NixOS

NixOS is a distribution for developers who want to focus on their development and who think in the declarative programming paradigm. It's a great distribution for people who want to create reproducible and maintainable systems.

It's much more stable due to it's declarative nature. You can't break your system by installing a package or updating your system, the nix package manager will block any breaks that happen and even if you do manage to break your system, you can always rollback to a previous state, fix the broken state, then build the system again.

It offers peace of mind with this idea since what you want as a developer is a stable, reproducible, and maintainable system that you can always go back to if something goes wrong and is backed up in a git repository that can be pulled any time and can be versioned with git to keep track of changes.

Sources