After taking Nix for a spin, I cannot be bothered to learn another custom tool with a bespoke language when I already have containers for doing the same things.
For Dagger, I can choose from a number of languages I already know and the Docker concepts map over nearly 1-1
That's also the case with the Docker ecosystem. On top of that, you need to take into account the base image, versions, etc.
At the end what I look for is for a project being able to build my source code with runtime dependencies and supporting tools that won't change overtime for the architecture that I need.
I have not yet encountered actual nix usage in my professional or open source work, so I don't see Nix as eating anyone's lunch
So yeah, no where near eating anyone’s lunch, let alone the behemoth that is Docker.
I definitely encountered packages available in homebrew but not nixpkgs, so the idea that if not in nix not in brew is wrong. Another package I use has been out of date for months, again it's quality over quantity and nix lacks the quality that i deem more important for myself
Someone else published a nixpkg for my project, but it is wrong. As an OSS maintainer, I have reduced the number of places I publish, too many packages managers these days for my limited time
This is an interesting problem you've faced, their marketing claim is that they have the most comprehensive catalog of packages (and I'm inclined to believe it). I very rarely run into broken packages, and that's usually resolved by using a stable release for that specific package - and it's not like my usage of packages is lightweight (7292 lines of nix config). That's on NixOS (and Silverblue, and Ubuntu) at least.
Things just work with pacman or dnf.
This is arguably a flaw in how Nvidia architected this, but it is what it is. The classical solution is nixGL [1], but this requires downloading special nixified versions of the libraries on every host system kernel change. An alternative option that I was involved in the development of is nix-gl-host [2], which manipulates the LD_LIBRARY_PATH for a Nix executable to allow it to link patched versions of the host's own userspace GL libraries.