@phoenix One of us, one of us!
But for real my number 1 tip is to put your nix config in git right away.
@phoenix @loon I mean, truth be told, as long as you have a computer with plenty of spare resources (disk, compute, but particularly RAM) and you have an emotional tolerance for specific kinds of system administrative headaches ("which of these umpteen versions of `less` am I using right now?" "Why do I need to use overlays - which are some funky time travel BS - to pin a version number for a transitive dependency?" "Ope. Some process got confused by one of its install dirs being read-only. Again." "THE ACTUAL FUCK, HOW AM I SUPPOSED TO DEBUG A BUILD ERROR 10 CIRCLES OF NESTED FP LOGIC DEEP??!")... like, yeah, you should be totes chillin'.
I first tried NixOS on a netbook with 1G RAM in the mid-2010s and I've never forgiven Nix since.
@phoenix @loon I dunno how much I can say for NDA reasons, but I think I can say a little, especially if I don't clarify which job.
We didn't actually use NixOS itself in prod, but we did use Nix and nixpkgs. It was for building artifacts like Docker images, which then ran in prod. It was also used a bit for local developer stuff on Mac and Linux desktops.
It wasn't my first encounter with Nix, I've used it a couple times before. Gods willing, I will not use it again. I find it so badly designed from a UX/engineering standpoint that it actually started me on the road of writing my own reproducible build/atomic installation package manager, which then derailed into writing a programming language for implementing the Layover package manager, which is why my account is full of posts tagged #pronelang today. You know how most package managers use efficient binary indexes of guaranteed-prebuilt binary packages, instead of a giant RAM-hungry interpreted FP language? There's a reason.