Nix is the basis of an OS distro: NixOS.

This article is just re-articulating the idea that {the/an} OS distro should be managing this stuff, and not some fledgling language-specific programs (that go behind its back, and do a half-baked job by not controlling the packages external to their language ghetto).

I'd go even further: Nix is just a build tool, like Make.

In fact, it assumes far less about the system than Make; e.g. Make does all sorts of shell-related things, whilst Nix simply executes a binary (with a list of arguments and a set of env vars).

(Nixpkgs definitions almost always use a bash binary as their executable, so it feels more like Make; but Nix doesn't care)

I'm confused; Nix mostly works by passing the '--prefix' argument to standard, off-the-shelf configure scripts. Some build/packaging tools don't seem to work with a user-chosen prefix, and hence need some sort of workarounds; but that's surely a fault with those tools.

> Horrible-horrible way to compute runtime-dependencies of packages. This may be okay as a heuristic to initialize a project, but in the end it must be tweakable manually.

I completely agree with this one. I've never experienced a problem with it; but that surprises me ;)

> This would be solved by a more modular architecture, where we can manage package with a one tool and build packages with a different tool. Until then, I would be forced to code in Nix, and that's problematic no matter how good the package management is.

The Nix store provides quite a nice separation between the "definition" side (where the Nix language lives), and the "building" side. In principle you can avoid the Nix language, e.g. the way Guix uses Guile Scheme. The only reason I use the Nix language is due to all of the definitions provided by Nixpkgs ;)

But I think the biggest issue is in your last paragraph where you don't describe why or how the solution needs to happen in the software itself rather than at a higher level.

Just like every other package manager, from rpm to dpkg, Nix is responsible only for the aspects of the filesystem that it's specified to be responsible for. It's not going to remove garbage left behind by users or poorly-written post-install scripts, and it's not going to automatically undo other non-filesystem-related state changes on package removals. And the practical reality is that not everything on a system can be a native package anyway.

A solution that works good enough is often a serious obstacle for developing a solution that works really well. E.g. Unix works just good enough to preclude the adoption of a new paradigm in OS'es such as Plan 9.

Treating packages like immutable values sounds like a genuinely new idea. So what I think is that people don't go "this seems better than my current development toolchain", instead they think that the idea that underlies Nix might result in disproportionately more reliable tools in package management. That's worth fussing about.

Disclaimer: I am not associated with Nix in any way.

The fundamental idea is this: Every package is built in a "hermetic" environment that guarantees that the only inputs are the ones you have explicitly specified. Those inputs include tools, source files, compilers, build instructions etc., all specified by a hash. Those inputs themselves can then be packages build in this way, such that everything in your system forms a big Merkle tree.

This approach enables a number of excellent things - you get excellent build reproducibility, you can cache any step you want etc. A lot of the concerns you get with a more conventional system just go away.

People have objections to Nix(OS) - the language, the sporadic documentation, some of the design decisions made, the learning curve etc. But I think those (very reasonable) objections obscure the more interesting debate about the underlying approach and value.

If the ideas seem pointless and confusing to you, that's fine, don't use it. There are bunch of great package managers and linux distros that will probably suit you better. But, if you see the need for declarative package management, then Nix is for you.

I'm a phd student in computational science. I use a bunch of different packages on my computer and I need to know exactly what I've installed and I do not have time to debug problems from dependency hell. Nix and NixOS have been two of the most interesting and useful tools I have every used. Not only have a gained huge productivity boost from having reproducible environments and declarative package management, but I've thoroughly enjoyed the process of learning these unique tools that, for me, are leagues better than any package management system I've used in the past.

If it didn't work for you, I hope you find a tool that suits you better. But that doesn't mean its bad. It might just mean it wasn't intended for you.

Despite its clear fit with the current hotness of immutable systems and functional programming, I don't think I've seen anyone in for-profit industry on a Nix/NixOps stack.

Nix fills a void in package management. It is like Ansible or Terraform for a semi-idempotent distro. It is probably quicker in most ways than building something similar with other configuration management tools, but I still prefer other tools because the language for Nix is just bleh. Had they went with a simple YAML format or HCL, then I'd give it a chance, but because they didn't I'm certain eventually someone will create something better learning from the mistakes of Nix.

I'd argue writing a Nix derivation isn't that different from writing a package definition for any one Linux distribution. It solves the distribution problem for people who use that particular distribution/tool, not everyone. Now, Nix can be installed on any distribution, but if I was going for widespread adoption, I might point to Nix being a solution, but I probably wouldn't advertise it as the main one.

I'd explain "functional package manager" as "package manager where packages are declared as a function of their inputs".

e.g. a package's inputs would be the compiler used to build it, and the source code.

One motivation for doing this is ensuring that a package's behaviour is reproducible.

There are all sorts of neat benefits this ends up allowing.

On the other hand, one of Nix's greatest strengths is that in many respects, its innovations are conservative. It brings software building and distribution forward in terms of reproducibility and isolation (like containers do) but (unlike containers) also retains the traditional package management virtues of granularity, efficiency, and sharing common resources (dependencies) when possible.

Engineers shouldn't assume something is done well because nobody is doing any better. Some things suck and there's nothing to blame but other priorities or sheer laziness.

Nix is often compared to Docker, but Docker is essentially just a way to run programs (in a sandbox). Saying "I'll build it with Docker" says how you're going to run it, but not what you're going to run. Unfortunately, the "what" usually turns out to be a shell script, which runs one package manager to fetch another package manager, downloads a bunch of files from some random URLs, etc.

Nix is all about keeping careful track of the dependencies between things, such that all the fetching has been done by the time our scripts start (access to the network, and any paths outside the build sandbox, is disabled by default).

Also, the way Docker tends to be used involves downloading an entire Linux distro, just to run those scripts. Nix does the opposite: scripts only have access to precisely what they've asked for.

Except not. I don't think "determinism" was ever an explicit goal of Nix. The sales pitch on their site is "learn how to make reproducible, declarative and reliable systems".

Nix takes very much a worse-is-better Unix approach. It aims to unify the mess of package management of Unix distributions and language runtimes in a reliable and easy-to-use way, but it doesn't aim to solve the computing world's problems in some quixotic quest for "purity".