We're onto the pedagogy thing. Check out the Nix book efforts: https://discourse.nixos.org/t/documentation-team-flattening-....

Regarding the language and "configurations" specifically, you might like what we do with Nickel: https://github.com/tweag/nickel. Research project showing a potential future for Nix.

Interesting. I don't find the Nix language itself especially complex, however, the whole system built with it is not that easy. For instance, packaging process is very well documented, making a derivation looked simple and reasonable until I decided package some code for myself. At this point things stopped being smooth. According to the documentation I needed to explicitly import my nix file from the top-level list of all packages which was not what I wanted, I'm unsure anybody except me would want my package (at least at the early stage of development). Intuitively, I was sure it wasn't necessary, there definitely must be a simpler way to toy with packaging but skimming through the documentation didn't reveal any answer. Looking at the source code left the impression that I needed a lot more time to understand how things worked behind the hood. On the other hand replacing pyenv with Nix was very pleasant experience. Overriding an existing package with my fork on github was almost a one-liner.

> According to the documentation I needed to explicitly import my nix file from the top-level list of all packages […]

Can you elaborate on this? I don’t follow.

The Nixpkgs packaging guide describes how to use the Nixpkgs packaging tools in the context of contributing to Nixpkgs, where to populate the package set with your custom packages, you add them on a top-level attribute in pkgs/top-level/default.nix.

But a lot of users want to leverage Nixpkgs while instead (or simply first) adding their custom packages to an overlay or a company repo of Nix packages.

From the [1]:

> 3. Add the package to the file pkgs/top-level/all-packages.nix. The Nix expression written in the first step is a function; it requires other packages in order to build it. In this step you put it all together, i.e., you call the function with the right arguments to build the actual package.

[1] https://nixos.org/manual/nix/stable/expressions/simple-expre...

I'm not so sure making nix comprehensible is realistic. When technologies fall under this level of complexity they require die hard fans to use it and keep it alive In all honesty, I would consider a complete rewrite at this point. I don't think there's a lot of hope for nix right now outside of hobbyists and researchers. Not saying this to be rude, but genuinely, take what you all have learned, take a sober look at the state of it, improve it. Almost no one will be willing to cope with it in it's current state docs or not. If it was the next docker/podman/etc you'd of known by now... It's not getting there, revert course

Recently someone has been trying to build a Nix package of an open source game I maintain, so I had a brief look at the project.

It does appear to be an experiment in package management that got out of hand. Basic usability is lacking, as I was unable to even get a listing of available packages on a NixOS virtual machine due to nix-env requiring well over 1GB of RAM. This flagrant waste of resources doesn't inspire confidence in the quality of the tools.

I'd rather see existing packaging data leveraged rather than adding a new language to the mix. Something like a translator or interpreter for RPM .spec files, for example.

Listing all packages is a bit of a weak spot. The entire package set is described in a lazy, functional language and listing or searching it requires evaluating the entire thing. A normal build will only require evaluating a small subset of the entire package list. `nix search` should have caching of results but it still requires evaluation to be populated.

> outside of hobbyists and researchers

No data on this, but I'm pretty sure Nix is used mostly by for-profit companies trying to tame complexity on a limited budget.

It's not nice or pretty, but there's very little alternative unless you're ready to keep a whole team of developers just fixing Dockerfiles all day.

I've used it in industry and it was nothing short of a disaster. Only one person could fix builds, despite many genuinely brilliant engineers putting in hours to learn it. More so, the time sink... Literally, what takes 29 minutes for a fresher to do in docker takes them two weeks with nothing to show for it in nix. Absolutely do not recommend it for industry whatsoever. Most people, except the one advocate for it, see it as a failed experiment.

If you work in a place where you have teams (multiple) of developers doing Docker crap, then nix is probably not for you.

To each his own, it targets an entirely different niche.

See https://nix.dev