Why Nix? - yet another take


Feedback welcome.


I personally love it

Alert: Sorry, ill be a little negative about this :cry:

So initially I thought that this article would be a way of selling nix to other people but this seems more of an explanation of what nix binary does.

If this is expected to be more of an explanation of what nix does and while it is an excellent little write-up but I don’t think that people who are not already familiar with nix would understand it. Maybe we should grab a couple of peeps unfamiliar with nix and see what they think?

And if you’d like to sell people on giving nix a try I think that article should answer the question “What Nix can do for me?”
I’d expect such write up to include such items:

  • Simplicity of packaging software with nix
  • Advantages of using nix for packaging (security, http://r13y.com, binary cache)
  • Development environment (devshell and integration with common editors)
  • Pipelines
  • Little mention of system management (NixOS, MacOS, home-manager)
  • Deployment

I feel like I’m missing context.

This page starts talking about configuration, and at the end extols how Nix’s string interpolation is neat. But I don’t get the benefit to the end user for why I’d like nix instead of dhall or jsonnet. I don’t get the jump from configuration management to talking about store paths and binary caches.

Also, some typos: e.g. “tought”, “immediatly”.


I think this is made explicit to point out that Nix isn’t just a configuration management language, of which there are many to choose, but instead choosing Nix comes with the unique benefit of actually building reliable and reproducible software artifacts.

It doesn’t really seem like a jump to me, the article says Nix has superpowers and then goes on to explain them.

That makes sense. I found it a bit confusing because I think of “configuration” as used for “input file to an application”.

I’d say one lens is “interface vs implementation”:

Nix provides a way for building packages reproducibly, with easy rollbacks, etc., and it implements this using a nix store with the help of its interploted strings carrying additional context. - I think in a "Why " page, it’s more straightforward to discuss the advantages of using the nix tool before discussing implementation details.

Any configuration language + ansible go brrrrrrr

Thanks all for the feedback. This is much appreciated!

I realize two things:

  • std is a DevOps/GitOps & Operator framework, it is not really targeted to packagers or distribution folks. I’m not sure if there would be an angle for them.
  • I may elaborate a little more on the packaging part still, even though for config management that aspect is at a different layer of the stack and the superpower is precicely that this stack is more transparently wired to the config management layer, than with any other config language, through a gigantic build-DAG. But anyway, maybe something like the following could be added in the mix: Packaging Principles - The Cardano Book
Hosted by Flying Circus.