[elt]

I was referring to using Nix as a tool for my own development workflow. You are describing a much more integrated and involved use of Nix (Nix packages deployed to production, Docker, etc).

That only cements the idea of avoiding Nix if you're using it for your own development workflow and the entire team/production deploy isn't on board with it.

[soraminazuki]

The real lesson here is "don't build production releases outside of a carefully controlled environment," not "don't use Nix." What led to the failure was the introduction of local dependencies to the production release. In your case, that dependency came from the Go toolchain that you happened to install using Nix. But uncontrolled dependencies could come from anywhere and the problem will persist as long as you don't take measures to control your build environment. This is where Nix really shines. It creates a controlled build environment. You can avoid Nix of course, but there's no avoiding the problem that Nix aims to solve.

> That only cements the idea of avoiding Nix if you're using it for your own development workflow and the entire team/production deploy isn't on board with it.

I disagree. Using it for your own development is fine as long as you keep it local. Either that or ship the complete dependency by building a Docker image as I mentioned earlier. Nix has various tools to make life easier even if it's only for personal development purposes.