I would love to see a discussion from somebody who really likes Nix on why it isn't ready for prime time yet/just play devil's advocate aloud on why it isn't the greatest thing since sliced bread. I feel like I must not be doing anything "serious" enough to need package reproducibility at that high level. I'm aware of things like git checkout/tags, package-lock.json, Cargo.lock, Docker image tags. What is a real worl…
I have several friends who use Nix and generally recommend it.
I do believe I think enough like them to like Nix for the same reasons (declarative, reproducible).
I've asked them to play devil's advocate, and I generally get the downsides, but...
There is one downside that I feel they can't tell me, but they end up telling me indirectly:
Nix is very complicated and takes a long time to learn. It's the Haskell of package managers.
I love Haskell, so it's not even unreasonable that I'll like Nix. But I won't like the learning curve. I spent a decade becoming productive in Haskell, and a year becoming productive in Rust. Will I like for my operating system to have crutches for months as I reconstruct my neural pathways to perform basic navigation?
This is why I think a tutorial like this is great: A gentle introduction, and a lot of courage to spend time, is all you need.
> It feels like the Kubernetes of package management/build if you will complexity wise.
In terms of learning curve, it might not be as bad as Kubernetes.
Kubernetes has a lot of complexity because of its distributed model.
But in terms of learning a new operating system with its own paradigms, it may seem similarly impairing to learn. (You'll lose the same abilities to run things until you figure out what's going on.)
> "Do we really need this or is it just what everybody else is doing?"
We definitely need reproducible builds.
Nix is the best solution to offer this.