Disclaimer: I'm a NixOS user who is interested in switching to Guix but have not actually tried it yet.
Both package managers (Nix and Guix) and the distributions (NixOS and GuixSD) are very young, so expect some missing packages and some rough edges. That said, Guix & co are newer than Nix & co, so expect more missing packages and roughness with Guix. Also, GuixSD being a GNU project, you'll have a harder time finding proprietary stuff packaged up.
Guix is entirely scripted in Guile Scheme, which is a strong point in my mind. And from what I understand, you can drive your whole operating system from emacs, which appeals to me as someone who lives in and loves emacs. It also has a strong emphasis on user Freedom.
But you can use both! This is part of what's so cool about functional systems. I personally started with Nix on Ubuntu, graduated NixOS, and am now starting to look into Guix. And eventually, GuixSD.
Guix uses Guile instead of the nix expression language for defining packages.
Honestly, I don't understand that choice. The main issue with nix is that is a lazy functional language and the learning curve for that is a barrier to adoption. But... scheme is not a solution to that problem. It looks to me like GuixSD the successor to the Hurd as the favoured GNU OS. It's the official GNU distribution of Linux and it's choices are more political/ideological than practical.
So you're excited to use an OS that's FSF-endorsed from top to bottom, choose Guix. If you're more interested in realizing the benefits of functional package management, choose Nix.
So, if you're more interested in functional package management
> Guix uses Guile instead of the nix expression language for defining packages.
> Honestly, I don't understand that choice. [...]
Then maybe you should not have written a whole paragraph speculating about political reasons.
Pretty much everything in Guix is written in Guile. The only exception is the daemon. The build derivations themselves are in Guile again. Having almost everything in Guile is great as it allows us to use different stages for code by quoting S-expressions. It gives programmatic access to package definitions and turns Guix into a library. This has proven invaluable as it made it quite simple to build a package manager web interface, recursive importers that take into account what packages have already been defined, package expression updaters, an Emacs interface using Geiser, a graphing tool, etc.
The values we hold also have an impact on how we approach functional package management. I'm working on reproducible Java, for example, building everything from source rather than accepting pre-packaged jars. This is a very slow process, but we are able to draw the complete dependency graph without having to accept binary blobs (e.g. for maven dependencies).
GuixSD is not the official GNU distribution if Linux, it's just part of the GNU project (Like Emacs isn't the official GNU text editor). And Scheme as the language for defining packages and even the system services is very powerfull, because you are able to do almost everything you want to.
From what I understand they will make a DSL when the time comes and they have realised what they need. Scheme is a really nice language, and the barrier should be almost non-existant if you know how to balance parens.
A DSL already exists. It's just embedded in Scheme, not an external DSL. Here's a package definition. You can see that it mixes regular Scheme (`string-append`) with new package-specific syntax (`version`, `source`, etc).
(define-public babl
(package
(name "babl")
(version "0.1.10")
(source (origin
(method url-fetch)
(uri (list (string-append "http://ftp.gtk.org/pub/babl/0.1/babl-"
version ".tar.bz2")
(string-append "ftp://ftp.gtk.org/pub/babl/0.1/babl-"
version ".tar.bz2")))
(sha256
(base32
"1x2mb7zfbvk9d0a7h5cpdff9hhjsadxvqml2jay2bpf7x9nc6gwl"))))
(build-system gnu-build-system)
(home-page "http://gegl.org/babl/")
(synopsis "Image pixel format conversion library")
(description
"Babl is a dynamic, any to any, pixel format translation library.
It allows converting between different methods of storing pixels known as
pixel formats that have with different bitdepths and other data
representations, color models and component permutations.
A vocabulary to formulate new pixel formats from existing primitives is
provided as well as the framework to add new color models and data types.")
(license license:lgpl3+)))
Both package managers (Nix and Guix) and the distributions (NixOS and GuixSD) are very young, so expect some missing packages and some rough edges. That said, Guix & co are newer than Nix & co, so expect more missing packages and roughness with Guix. Also, GuixSD being a GNU project, you'll have a harder time finding proprietary stuff packaged up.
Guix is entirely scripted in Guile Scheme, which is a strong point in my mind. And from what I understand, you can drive your whole operating system from emacs, which appeals to me as someone who lives in and loves emacs. It also has a strong emphasis on user Freedom.
But you can use both! This is part of what's so cool about functional systems. I personally started with Nix on Ubuntu, graduated NixOS, and am now starting to look into Guix. And eventually, GuixSD.