I oscillate back and forth between guix and nix. They both do the same thing really well. Nix is more mature, has some amazing capabilities, and is kinda annoying in spots such as documentation. I end up browsing users' repos for both.
Guix is more elegant in ways such as guile versus nix the dsl, although the haskell underpinning of nix is very useful.
If you're a linux user willing to put in the time and play around then both are perfectly usable as daily drivers but they're both learning experiences as well.
Hard to say which will win out, probably both, with excellent interoperability.
They really are the future of os managment, they simplify abstractions of state and naming
What kind of interoperability should I expect between Guix and Nix going forward? As I understand, Nix is pretty heavily reliant on systemd for running services while Guix has its own pid1. Last I read Guix was also replacing the daemon with one written in scheme. I think Guix used Nix package format (nar) at one point but not sure if that holds anymore either.
The idea of two functional, declarative package/system managers being interoperable is very exciting for me, if it meant I can use full breadth of Nixpkgs with system config declared in Guile. But is that something I can look forward to or is it too much?
Nix exists as a service for guix. All my system declarations include the nix service. But as far as interop goes I’m not really sure of the value. I think it just sounds neat but hasn’t really been thought through in terms of exactly what that would look like.
Nix itself is written in C++, but Nix the language borrows multiple characteristics from Haskell. Nix community and Haskell community are also very comfortable and comingled with each other and Nix is one of the recommended ways to manage Haskell project dependencies.
Haskell and the Nix language are both pure and lazy extensions of lambda calculus, but that's an enormous language space, and Nix's lack of static types makes them pretty distant.
For many Haskellers, I believe the interest stems from how Haskell's "cabal-install" (its closest equivalent to pip, cargo etc) used to be pretty broken. There wasn't universal interest in fixing this, with some insisting that installing dependencies is the job of your distro's package manager, not your language's ecosystem.
Gentoo did an okay job at having coverage of Haskell dependencies, but Nix was the clear leader ever since they could auto-import the hackage database. It's for this sole reason that I moved from Gentoo to Nix.
This pipeline I came through doesn't really exist now, because the Haskell community has endorsed Stackage, and cabal has fixed its core problems by copying the nix solution.
Usually with esoteric distros you run into problems with binary packages and packages based on uncommonly used languages.
It'll probably work as a daily driver if you mainly live in a web browser and don't do GPGPU/games/new languages/etc. If you don't mind building from source you can even do most of those.
For what it's worth the project seems very well structured and the contributors very competent and motivated. I am tracking the project.
> if you mainly live in a web browser and don't do GPGPU
For what it's worth, I use Guix and I've been able to do everything but CUDA just fine. (CUDA will never be supported in Guix as it requires proprietary drivers to function.) There are opencl packages, for example. It works well enough to run an Ethereum miner, Blender, and even games in WINE. I've been meaning to package AMD ROCm for better GPU compute support.
I use it as a package manager on another distro (in my case, popos; that's how a lot of people use it afaik). Considering using it as a VM. It works quite well as a supplementary package manager, but has glaring deficiencies with some languages / build systems (gradle, npm, Julia, etc.)
