Hacker News Reader

Comment by Tomis02 | Hacker News Reader

> Nix only exists to be the language for Nix, the package manager. While people have occasionally used it for other use-cases, it is explicitly not a general-purpose language.

The next question is why is the Nix package manager needed and why should a software developer care. I don't know the answer.

View on HN

Nix allows you to install packages without naming or version conflicts. It allows you to make source repositories act as first-class packages. It can be installed on any Linux distribution and MacOS. Changing and customizing packages is trivial. All the building and installing happens outside of the source tree, so you don't clutter up your $HOME. It's reproducible. It's simple. And it's build with the needs of Free Software in mind (unlike snap or flatpak which seem mostly concerned with packaging proprietary software). Also Nix is 20 years old at this point.

Simply put, with Nix I can do:

   nix run github:project/name

to run a program. Not many other package managers are capable of that.

That's cool but Brew seems to work just fine for my needs (and most developers on a Mac, apparently). Which is why I think the question still stands; unclear why people should care when the status quo is good enough.

Software developers often want to customize:

1. their home environments: for packages (some reach for brew on MacOS) and configurations (dotfiles, and some reach for stow).

2. their development shells: for build dependencies (compilers, SDKs, libraries), tools (LSP, linters, formatters, debuggers), and services (runtime, database). Some reach for devcontainers here.

3. or even their operating systems: for development, for CI, for deployment, or for personal use.

Nix provision all of the above in the same language, with Nixpkgs, NixOS, home-manager, and devShells such as https://devenv.sh/. What's more, Nix is (https://nixos.org/):

- reproducible: what works on your dev machine also works in CI and in prod,

- declarative: you version control and review your configurations and infrastructure as code, at a reasonable level of abstraction, to specify what the system should be, not how to get there,

- reliable: all changes (switching generations or profiles) are atomic with easy roll back.

Thank you, it makes sense. I guess these points would resonate with me if I had the problems you describe. Fortunately, I usually don't. The less I fiddle with packages, dot files, shell scripts, the better my life is.

Have you tried Google?

Reply on news.ycombinator.com