[teh]

Guix comes up on every Nix thread on HN and it's a bit frustrating. Guix runs on Nix technology with a new config language for packages & a different philosophy about what can go into its core package set (it's a GNU project).

My personal take is that the difference isn't large enough to warrant a new distribution and if you want to choose you should go with the momentum and that's with core Nix (10-30x contributors, 10-100x packages, depending on how you count).

People also think scheme is better than Nix as a language, but if you reason backwards from the requirements that's not at all clear to me. I think Nix-the-language would be better off with types, but the lazy, functional & pure parts are necessary for the concept.

[davexunit]

>Guix runs on Nix technology with a new config language for packages & a different philosophy about what can go into its core package set (it's a GNU project).

This is a common misunderstanding. Guix is not just a new config layer on top of Nix, it's a new implementation of the concepts pioneered by Nix. The only component that is shared between Nix and Guix is the daemon (written in C++), and they have diverged quite a bit at this point. Everything else about the core implementation (UI, the client for the daemon, recipe->derivation conversion, initial ram disk, init system, etc.) is implemented in Scheme and has pretty significant differences with Nix/NixOS. Even the Guix daemon will be written in Scheme eventually.

>People also think scheme is better than Nix as a language, but if you reason backwards from the requirements that's not at all clear to me. I think Nix-the-language would be better off with types, but the lazy, functional & pure parts are necessary for the concept.

This is another common misunderstanding. The part that is necessary for the concept is that the derivations, the things that the package recipes are transformed into to be built by the daemon, are computed lazily and act as pure functions. Guix certainly retains this quality. Also, if you look at the Scheme code in Guix you'll find that it's written in a purely functional style. I think Scheme's multi-paradigm nature is a strength, not a weakness.

[teh]

Apologies for misrepresenting - my Guix knowledge is clearly out of date!

OTOH disagree with many of your choices and the assumptions you based them on. But I also think that this would easier to discuss in a civilized face-to-face than over the lossy, easy-to-misinterpret medium of text on the Internet!

[mbakke]

I agree that the endless Nix vs Guix discussions are getting tiring.

As a contributor to both, I'll try to explain why Guix won't make Nix obsolete any time soon:

Guix is an official GNU project, meaning they won't ever support any proprietary code. The Linux kernel is "Linux-libre", which is a Linux fork with all proprietary drivers removed, so it probably won't run well (if at all) on your laptop. Whereas on NixOS you'll have things like Steam working out of the box.

Guix also has an unfair advantage in that they started "from scratch", while Nix contains a lot of legacy cruft from "paving the way". The `guix` tool/frontend is a lot better than the various "nix-*" commands, but there is work underway for a similar unified interface to Nix.

Finally, the language: Scheme is more pleasant to work with, but I find system configuration a lot more intuitive in Nix. NixOS also uses systemd/udev which is more familiar for most people than the maturing Shepherd service manager in GuixSD.

TL;DR: Nix and Guix serve different purposes through similar means. They are both excellent distributions and clearly represents a new era of operating systems. Most people would want to go with NixOS if they want a minimal-hassle functional operating system; but if you are just looking for a decent package manager for your favourite distro then Guix may be a better choice (as long as you can live without any non-free software).

[dorfsmay]

> Guix comes up on every Nix thread on HN

Sorry, and thanks for taking the time answering.