> Whatever package is thrown your way, you can rebuild it locally and check whether you have the expected build output. This is analogous to verifying a binary downloaded from the Web by computing its sha256 hash, and comparing it to the one provided by the publisher of the binary.

Can someone explain this to me?

There is an experimental feature to add content-addressable packages that will give you this, but Nix package hashes are hashes of a package description, not the package, so you can't use them like a checksum. You can say "Hey do you have this package I want?" and a server can use the input hash to find what you're talking about, but there's no way that you can verify that what they gives you represents a good-faith attempt to build the package.

I would also be very surprised to learn that a significant portion of Nixpkgs is "bit-for-bit" reproducible. That's hard! It's hard enough to get packages to work with Nix at all, and very few compilers/build systems/etc are actually concerned with literal reproducibility. Nix doesn't magically provide that.

(There are also "fixed-output" package descriptions which are mostly used when you're downloading sources from the internet -- those actually are checksummed and verified, in case the remote source changed. I guess you could use that same mechanism for a build output, but you... don't?)

Anyway, maybe this is a reference to the (experimental! bleeding edge!) content-addressable store stuff, but I don't think it's fair to call that a selling point of Nix yet. (Or I am way out of line. I don't really know what I'm talking about.)

> Why is this important? Because it removes the need to trust the provider and makes the cost of detecting a failure or an attack much lower for the developer. Reproducibility means security for your systems and applications, and peace of mind for your developers.

There is a large amount of trust when you download a binary Nix file, which is why you have to configure only trusted cache servers, and why cache servers will only accept submissions from trusted sources.

Reproducibility is really important, and a great feature of Nix -- you can, given a package description, build it yourself instead of downloading it -- but emphasizing security and trust seems very misleading to me. If someone can clarify these points I would appreciate learning something new about Nix.

> Nix undoubtedly has a steep learning curve, and there are two reasons for that. First, using Nix entails rethinking a lot of accepted wisdom and practices that have become second nature for a developer. Unlearning is hard. Second, Nix surfaces all the complexity involved in building software and forces you to deal with it. In order to make builds truly reproducible, this is largely inevitable.

I disagree very strongly with these two statements. This reads like "It's not Nix's fault that it's hard to learn; it's your fault for not trying hard enough."

I think that's absolutely not true. Nix is hard to learn, and it's mostly Nix's own fault -- which is a good thing! Because it means that it's fixable. Nix's approach to package management isn't some fundamentally difficult concept to wrap your head around. The concepts and ideas are pretty straightforward, once you understand them -- but how are you supposed to understand them?

The Nix manual is sort of infamous, and not without reason. Nowhere in the manual will it teach you how to write a standalone package description -- although it will show you how to contribute one to the Nixpkgs repo, which is a pretty different flow. It doesn't really explain the high-level mental model I have of the Nix store as a simple graph database. There is almost no coverage of nix-shell, or the things it can do (which include some really cool things! Shebangs that explicitly list all of your scripts dependencies!). The quick start guide, until quite recently, explained how to install packages using the "wrong" command -- `nix-env -i git` -- which takes about a minute to run on my machine. (The "right" command -- `nix-env -iA nixpkgs.git` -- is instantaneous.)

But it's not just the documentation's fault. Why is there a wrong way to install packages in the first place? It's one of many weird historical mistakes, which are all forgivable independently, but which add up to one of the most confusing and inconsistent command-line interfaces I have ever used. `nix-env -e` takes glob-looking things, but `nix-env -q` takes regular expressions... I dunno. There are tons of things like that. (There is a new command-line interface that you can opt into by editing a Nix config file, which is much better, but not without its own fun new set of problems.)

In my experience the incidental complexity of Nix was a much larger barrier to learning about Nix than the "actual" complexity of bundling and building software that the article places the blame on.

In case this wall of text should come across the wrong way: I love Nix, and I wouldn't want to give it up for anything. I switched away from Homebrew about a year ago and haven't looked back. I am someone who writes a lot of random scattered projects in lots of different languages, and being able to document "system" dependencies on things like pango or imagemagick or pcre or whatever is really useful for me, as a way to augment my cabal files or package.json files or whatever else.

But it was pretty hard to learn how to wield it effectively. And I wish that others could experience the benefits without having to go through what I did (although if you want to go through what I did, I wrote about the experience here: https://ianthehenry.com/posts/how-to-learn-nix/).

Someone already said this but yeah, Nix the idea: long overdue. Nix the implementation: maybe check back in a couple years.