As a NixOS user who loves Nix yet struggles with nixpkgs from time to time - The main issue is that nixpkgs is unapproachable to new users. Yes, there is the d

As a NixOS user who loves Nix yet struggles with nixpkgs from time to time - The main issue is that nixpkgs is unapproachable to new users. Yes, there is the documentation at https://nixos.org/manual/nixpkgs/stable/ https://nixos.org/manual/nixpkgs/stable/ , and it is quite long. It's not enough. Every Nix tutorial basically starts off with "this is how you create a new package. You get your source with either ./. or by using a fetcher to download a release from the Internet. Then you use mkDerivation to package the release by writing the install scripts." OK, cool. Then you want to package a Go program. Cool, let's copy from an example in nixpkgs. Well, stuff in nixpkgs doesn't use mkDerivation, it uses buildGoModule, and it references weird SHA hashes for the vendor? How do you get those? So you go to https://nixos.org/manual/nixpkgs/stable/#ssec-language-go https://nixos.org/manual/nixpkgs/stable/#ssec-language-go and it doesn't explain to you how to get the vendor hash. It doesn't explain to you why nixpkgs uses buildGoModule and not mkDerivation. So you don't really know how to continue and you feel pretty stuck. The thing is, a) buildGoModule is a higher-level function that will return the result of mkDerivation in a way that reuses everything that is common to Go modules. So it makes perfect sense from the perspective of a maintainer who wants to reduce the size of nixpkgs as much as possible, which is already one of the largest Git repositories on GitHub. b) Nixpkgs library functions like buildGoModule, with the need to maintain the separate vendor hash, come from a desire to write pure Nix functions without network access, i.e. there is no need to re-download the vendored dependencies if they already exist in the local Nix store cache. Indeed, the fact that there is only a single vendor hash represents a pragmatic compromise; whenever any dependency changes, the entire vendored dependency tree needs to be re-downloaded and rebuilt; if the hashes of the individual dependencies were tracked, then Nix would understand to only download the dependencies which had changed. The reason why Nix can't compute the dependency hashes of each dependency internally, and only then try to check the Nix store and see if they exist there, is because Nix does not yet support recursive calls: https://github.com/NixOS/nix/issues/13 https://github.com/NixOS/nix/issues/13 (nearly ten years old). However, the RFC for adding support was finally merged: https://github.com/NixOS/rfcs/pull/92 https://github.com/NixOS/rfcs/pull/92 and so support will come soon enough. So basically: Given that most developers need to produce containers to ship to production, and Nix already makes it possible for developers to ship containers, Nix needs to make it easier for developers to build their services/programs in Nix. Program build support is already pretty great for some specific ecosystems (e.g. Haskell) but for most ecosystems (like the Go example above) it ends up being pretty frustrating for one reason or another, due to lacking language features. Once those features are developed, there's a lot of room to make huge improvements in the various lang2nix projects, and then much more of Nix's value will be accessible to developers.