For background our product is an online game and related services (social, persistence, auth, analytics, etc.) written primarily in C# (some JavaScript and Python), running inside Ubuntu docker containers, using the Hashicorp stack (Nomad, Fabio, Vault, Console, Boundary, Terraform). Our services run on multiple cloud providers. As you might imagine, we have a complex environment with a lot of services. We wrote a lot of scripts & tools to automate builds & deployment, and create per-project environments using direnv+Nix.
On the plus side our local development machines behave identically to dev/staging/test/prod branches in the cloud. We've not had any issues where our apps and deployment work correctly on one computer but not on others because everyone uses the same version of software packages. We're able to run partial sets of applications all the way up to the full set of services locally, which helps when debugging complex transaction chains.
On the downside, only one person really knows Nix well, and -- so far -- we've been entirely dependent upon him to make Nix work and perform version upgrades. Occasionally it's necessary to solve dependency problems when some application doesn't work properly, like where a project used Python3 + AWS CLI v2 and just wouldn't build.
I've looked into making changes a couple of times, but the amount of lore that's required is so frustratingly large! I've got a lot of experience solving hard problems in development & operations, and I want to cry every time I start in on it to fix some esoteric bug.
You'll want at several experienced Nix folks on staff; it's not for the fainthearted.
My impression was fairly painful. I spent weeks troubleshooting small issues just trying to get it set up. The root issue ended up being something with how I configured it's repo of recipes/flakes/can't remember the term. The error messages weren't super helpful, and Nix doesn't seem to have enough penetration that even dumb errors caused by misconfiguration are googleable.
Given that most of our apps were distributed via tarballs or git clones prior to this (meaning no complex dependencies between them), I was more inclined to use something more similar to that (namely yum, apt or dnf). Having to re-do our builds and deployments at the same time was fairly painful.
Lastly, I don't feel like we really reaped any rewards. Tarballs forbid us from establishing complicated dependencies, so a lot of the pain points that Nix fixes just didn't apply. The things that Nix makes more painful were definitely felt, though.
Overall, it's something I might try if I were somewhere greenfield. I still think I would lean towards a traditional package manager or containers, though. Nix introduced a lot of friction for me, and it feels unlikely that the issues Nix solves would cost me more time than the constant friction of Nix.
The company I work for right now uses NixOS for all* Bare-Metal Hosts and VMs that run atop them. Personally I run my Home-Lab/Personal-Computing-Setup all on NixOS.
You have to consider that Nix is a language (turing complete, for describing build-processes) and treat it that way too. It has a similiar, if not harder, learning curve to other languages. Especially since most people are usually not exposed to concepts such as lazy evaluation, functional programming, etc.
: )