While the author raises a number of legitimate points, many of them are debatable and some are just pure hyperbole. > Guix uses so called build systems ... Nix

While the author raises a number of legitimate points, many of them are debatable and some are just pure hyperbole. > Guix uses so called build systems ... Nix does have build phases, and even something similar to build systems, but ... These build systems aren’t documented anywhere, at least as far as I could tell. Nix has stdenv.mkDerivation and various functions based on it in Nixpkgs. Documentation leaves a lot to be desired, but they do at least exist in the Nixpkgs manual: https://nixos.org/manual/nixpkgs/stable/#part-builders https://nixos.org/manual/nixpkgs/stable/#part-builders > All Guix package definitions are written exclusively in GNU Guile - a Scheme implementation. ... For example rather than calling a sed within a shell script like what Nix definitions sometimes do, Guix uses the procedure substitute* instead. Nixpkgs does use Nix functions to abstract away shell commands, but it doesn't attempt to replace shell commands entirely. Since build scripts are generally based on shell commands, I find the Nix approach of making it easy to embed shell commands reasonable. > Now for the Nix language. It’s poorly documented. ... It isn’t particularly good as a DSL I disagree with this assessment. Nix the language is a very small and conceptually simple language. It's basically JSON with functions. Its main competitor is JSON and YAML, and Nix does a far better job at describing complex data than those two. The Nix language is documented in the Nix manual. Since the language is small, the relevant section is a quick read and easy to understand. https://nixos.org/manual/nix/stable/language/ https://nixos.org/manual/nix/stable/language/ In contrast, Nixpkgs, the standard library of sorts, took more time to understand. But I soon figured out that grepping the Nixpkgs repository generally turns up many useful samples. > Many packages also aren’t bootstrapped properly, instead patching and repackaging .deb packages and the like. I can't find a source for this claim. I grepped the entire Nixpkgs repo for references to .deb or .rpm files. There certainly are packages that repackage them, but they're for proprietary software. There's no other possible way. Using prebuilt binaries when source code is available is frowned upon by the Nix maintainers and won't pass through review unless there's a very good reason. > Nixpkgs is unreliable - this speaks for itself… This is highly misleading. The linked discussion mainly refers to the burden placed on Nixpkgs maintainers. While that is a serious problem, summarizing that as "Nixpkgs is unreliable" isn't fair. Or do changes in the Guix master branch not introduce regressions? > home-manager? Has it’s own issues. It’s also not well documented. The linked issue is a list of things to consider when getting started. Again, it's not a fair characterization of what is actually written. Also, every Home Manager option comes with documentation: https://nix-community.github.io/home-manager/options.html https://nix-community.github.io/home-manager/options.html > Overall Nix is a very flawed piece of software and far inferior to Guix. Pure hyperbole and also not an acceptable thing to say. > Years and years of technical issues plague the project and there seems to be little interest in actually resolving these issues. I get the exact opposite impression when I look at discussions taking place on GitHub and Discourse.