Even if you need something just once, just install it and then uninstall it, takes like 10 seconds.

apt install foo && apt remove foo

That's essentially what nix-shell -p does. Not a special feature of nix, just nix's way of doing the above.

Actually using it though is pretty convenient; it disappears on its own when I exit the shell. I used it just the other day with nix-shell -p ventoy to install ventoy onto an ssd, I may not need that program again for years. Just used it with audible-cli to download my library and strip the DRM with ffmpeg. Probably won't be needing that for a while either.

The other thing to keep in mind is that since Nix is meant to be declarative, everything goes in a config file, which screams semi-permenant. Having to do that with ventoy and audible-cli would just be pretty inconvenient. That's why it exists; due to how Nix is, you need a subcommand for temporary one-off operations.

Like literally what’s the point of having a shell with ffmpeg? Why not simply install it? Even if you need something just once, just install it and then uninstall it, takes like 10 seconds.

The last time I used it, I needed arandr just to create a layout with a new monitor. Why would I install it, use it, remove it, and then auto remove the leftovers when I can just run a single line to use it once and forget about it? My old installs were littered with random crap like that that I've used once and forgot to remove.

The other use case that is often brought up is for managing dev environments, but for a lot of popular languages (Python, Node, Java, Rust, etc. ) there are proven environment management options already (pyenv and poetry, nvm, jenv, rustup).

Here's the last time I used it: I needed to compile some rust binary but I don't have rust or cargo installed. Since the repo has a nix flake, I was able to clone it, cd into the directory, run "nix develop", and start compiling. Much easier than having to find and install all of the compile time dependencies, and then remove them a minute later.

Besides that, there's a reason why python has different 20 venv packages: they're all crap. Nix is a better alternative and leaves you with a single dependency for every OS.

Not to mention Docker. In the corporate setting I haven’t seen nix replacing any of these.

Declarative package management definitely has it's benefits, and nix has been growing in that space ever since they've added the option to generate docker images from nixos configs. It's not meant to replace docker, just to give you an option to create finely tuned base images.

GUI app shortcuts work in neither of the OSs

Home-manager on Debian: no manual set up was required.

error messages are about as readable as the ones you get for C++ templates

They can get overly long, but perfectly raadable if you start from the bottom.

All in all nix seems like a pretty concept but not too practical at the moment.

Nixos sure, but with nix I get the same bleeding edge userland packages on Debian and whatever else I'm running at the time. It's just a list of packages, but it makes life so much easier.

I often stumble on this example of nix usage - a one-off shell with a a specific package. This is such a niche and seemingly unimportant use case, that it’s really strange to have it mentioned so often.

It's probably one of the simplest things you can do with it that isn't really possible with other package managers and also doesn't require explaining any internals, I guess that's why.

I could also tell you about easily being able to build statically linked binaries or cross-compile (or both) with the same package definition without having to do any extra work, that might be more impressive.

The other use case that is often brought up is for managing dev environments, but for a lot of popular languages (Python, Node, Java, Rust, etc. ) there are proven environment management options already (pyenv and poetry, nvm, jenv, rustup).

Yeah, and neither of them considered that it might be important to deal with software written in other languages. Want to link against a C library in a Rust project? Run some tool as part of NPM build step? Screw you, install it manually from elsewhere or your build fails. The only one that I know does do this is OCaml's OPAM, which does have a lot of non-OCaml software packaged. (Also at least the latter three seem to be only for setting up the language itself. What is this, a package manager for a single package?)

Not to mention Docker.

Meh, Docker is kind of a joke. Sure, it solves the problem of dependencies, but in possibly the stupidest way possible bar shipping a VirtualBox image. A lot of prebuilt images are x86_64 only. It needs to run a Linux VM on Mac and Windows (tbf Nix doesn't have a native Windows version at the moment either, you need to run it in WSL, but people are working on that). So that means running at native performance on an ARM Mac, which are quite common for development I think, is out from the start. It also adds a lot of complexity to your environment due to wrapping everything in a container if you just want to have a couple tools. You don't get your nicely configured shell, other system tools, anything else inside the container. I haven't ever tried it but you probably also need special support from any IDE you want to use.

(And not to mention most Dockerfiles being absolutely not reproducible, but you can solve that... with Nix :^) )

• GUI app shortcuts work in neither of the OSs

On Linux I think you need to link ~/.local/share/applications to home-manager's share/applications. Not sure about Mac, its GUI kind of hates symlinks and Nix uses a lot of symlinks. Spotlight doesn't read anything behind symlinks at all, for example, and Launchpad resolves them so after a package update it will not pick up the new versions because it's still looking at the old path.

• error messages are about as readable as the ones you get for C++ templates

Unfortunately true, yeah. I also think this isn't really a problem that can be solved due to Nix being a dynamically typed language that has everything be an expression (so there's no fixed structure whatsoever) and also using lazy evaluation everywhere. Three components that all decrease the capability for useful error messages and debugging, and together… yeah it can get pretty bad.

• a lot of troubleshooting searches to unsolved GitHub issues

Really? This hasn't been my experience at all. There's a couple like that, sure, like the build sandbox on Mac, but they're rare. And usually people in the community channel know a workaround :^)