I've been using Nix at a startup for about a year now. For us, the value is easy and exact replication of an application's execution environment. Setting up a d

I've been using Nix at a startup for about a year now. For us, the value is easy and exact replication of an application's execution environment. Setting up a development environment for a new hire is just a matter of cloning the repository and running nix-build. (Though for some apps, there's also a third step: run a script to set up the database.) Once an app works in the dev environment, it just works in staging or production. That's not to say that we never have configuration issues, but mostly they come from weirdness in 3-party packages. For example, recent versions of `node-pg` (postgresql bindings for node) have an implicit dependency: if you want to use the native library instead of the pure-Javascript implementation, you must also install `pg-native` alongside pg. That's just in the README, though, there's no peerDependency declared in pg's package.json file, so npm2nix can't generate the appropriate nix expressions. Using nix definitely gives you the sense of swimming upstream, because the rest of the world doesn't understand this stuff and doesn't care. But for us, it's been worth it.