Given that I just fleshed this out in a random reply on reddit, I thought I could copy&paste it here in case anyone’s interested. For background, those are some pain points I personally have with NixOS (partly applies to non-OS nix+nixpkgs usage too), after experimenting with it for some time on a spare computer at home.
Please note I’m fully aware of the huge Nix/NixOS advantages. I don’t list them here, because we all know them. This is in no way meant as an “attack”, “flame/flame war” or whatever; sorry if you find it harsh, you can just ignore this post. I just thought some people may understand the value of some harsh but honest experience report of a newbie-gone-intermediate NixOS user. To repeat, I totally know of NixOS advantages; those are what has drawn me to Nix/NixOS, made me experiment, and still makes me want to experiment at home. But notably, those are points which especially make it difficult for me to currently recommend NixOS at my workplace.
Without further ado, in no particular order (but numbered for easier reference):
- multiple stacked variants of legacy approaches to various stuff & configuration (the “lava layer antipattern”) in nixpkgs; good example of the problem is vim;
- some areas are poorly documented (notably with cross-compilation I felt on my own, even the people on the mailing list could not help me with some non-trivial cases); the Nix & NixOS manuals are awesome and indispensable, but I quickly found out that soon afterwards you have to just dive in the nixpkgs repo and use it as the main source of truth, referring to the manuals as a kind of “base reference cards/sheets”;
- “to pin or not to pin”: when staying with a NixOS release, I quickly started to miss newer packages; when following nightly, I was afraid of things breaking and the config being not really reproducible; I tried to reasearch nixpkgs pinning, but didn’t manage to find a lot about this (reportedly doable, but haven’t found good examples I would be able to reuse);
- problems with hookability because of encapsulation: I started with
.nixpkgs/config.nixand overlays for Nix, and
/etc/configuration.nixwith NixOS; but after some time I realized you can only do so much with them, as packages tend to be quite encapsulated, opening only a few parameters for public modification; IIUC, for deeper hacks/customization the de facto canonical technique seems to be to fork nixpkgs and maintain your own set of patches over it. This feels like notable trouble from maintenance perspective. (I think this is exacerbated by the difficulty of contributing back upstream; I’m fully aware this is a known problem in the community, discussed a lot, and efforts are taken repeatedly and relentlessly to try and solve this.)
- (introducing new, niche language in the codebase; as much as I like the Nix expression language, and understand its advantages, there’s no escaping that it being niche and peculiar must be accounted for as a cost from maintenance perspective; I cannot deny Ansible has it better here by using YAML+Python.)
- (popularity (i.e. ease of googling for solutions); absolutely not in any way a fault of Nix, but life’s not fair and Nix just starts with a handicap here compared to Ansible.)
I put the last two in parentheses, as I don’t see them as something that can (or should) be easily fixed, but this being a real “experience report”, I wanted to note, that when evaluating NixOS for use at work, I felt I cannot skip them if I want to be honest (comparing e.g. to Ansible).
By the way, I feel that 3. and 4. may be where I just haven’t found a good solution yet, so I’m especially open to suggestions here. But at this point I stand by my opinion that I do firmly see them as pain points, given that I put quite some effort to try and research them for myself. What can be said for sure is that some official documentation on recommended practices/approach here would be useful.
Also please note I last dabbled with Nix I think some 12+ months ago. I’d be happy to hear if any of this is now outdated.