Hacker News Reader

Comment by rgoulter | Hacker News Reader

Neat article.

For me, the key takeaways are:

1. 'Nix is to `tar -xf && make && make install` as C/C++ is to assembly'. In many ways, Nix applies the same kinds of improvements that other technologies have.

2. Nix does try and create an elegant programming model of Unix systems.. while the Nix programming language is pure, it interfaces with the Unix system by reading files and outputting files.

I'm mixed on to what extent articles like this get to the goal of make Nix more accessible, though. It seems like preaching to the choir to me: if you like the idea of making analogies between "software is files, is like dealing with raw pointers", you'll prob'ly love diving into Nix as is anyway.

View on HN

Same. I read almost every nix-related post that I see pop up on HN. I want to be convinced. I have not yet been. It seems like `brew install` with (many) extra steps, with little meaningful gain.

I'd describe many of the benefits for developers as like "docker, without containers".

e.g. if you want to try out helix, you could run `nix run nixpkgs#helix`, and it would download + run helix without installing it. (Or you could run `nix shell nixpkgs#helix` to add helix to the PATH in the current shell, without installing helix, etc.).

One use case I'm excited about for developers is the ability to declare the dependencies needed to build the project. -- So rather than copy-pasting `apt-get install` commands, you'd rely on nix to fetch the installed dependencies. (e.g. I love that I don't have to worry about what packages to install to work on qmk_firmware, or repos which provide a nix shell).

VSCode's Remote Containers supports a similar workflow to the latter.. but, it relies on containers.

We use Brewfiles to install binary dependencies needed by various projects. This is only for developer’s machines, but it’s lightweight and fast: `brew bundle` and you’re done.

What happens when you have two projects that use two different versions of the same dependency?

With Nix, you can "install" many different versions of the same program side by side in the store, and then "activate" the one you need at runtime (or with direnv).

Has never happened. I know this is something that is given as a benefit of Nix, but I have personally never encountered the situation. For every project I have worked in professionally their tool chain was standardized enough that the situation never arose.

If parallel installations like you describe is a requirement — and I’m sure that it is — then Nix looks like it could help. That’s just not something I have ever found myself needing.

With node this happens everywhere all the time hence the popularity of tools like nvm or fnm. At my current company we have projects that absolutely require java 8, or 11, and I'm sure we'll soon have Java 17 only projects, sometimes with corresponding needs regarding tomcat or maven etc. versions. It's also a common complaint with python and the most common solution seems to be a bunch of python3.x packages from your package repository, though there have been tools like tox or pyenv for this and others that try to combine solving this problem and virtualenv management.

That said, if you just want language generic toolchain management, asdf seems to have a much lower barrier to entry.

Personally I have been using nix as a homebrew replacement, because it allows me to sync my packages and versions between my personal Arch setup and my day job Mac OS setup with a single configuration

Important difference: Docker is repeatable, but not reproducible. Nix is reproducible.

Nix is an abstraction around `tar -xf && make && make install`. In fact, those commands are even executed by nix, just in a sterile reproducible environment.

What sets nix apart from other package managers is that you are never running `make install` on your root filesystem, but `make` can still dynamically link to libraries (that also aren't installed on the root filesystem) without editing the Makefile directly to find them.

This way, you can't break existing packages, you can trivially roll back changes (because updates are new instances), and you can always start over fresh.

The only problem is that you have to wrap every package in a derivation, then publish that derivation somewhere. Right now, all derivations are tracked in a single git repo (with dozens of branches), all coordinated over GitHub Issues, and referenced by nix itself by an arbitrary (versionless) name in a global namespace in this file: https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/...

That last bit can be avoided by using pinning and flakes, but it's still the default way to use nixpkgs, and documentation doesn't clarify much or offer a better consistent UX paradigm.

Reply on news.ycombinator.com