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
