Earlier quoted context omitted.
As a NixOS user who has (recently!) played with Guix, I don't think ‘battle testing’ is a great reason to prefer Nix. Guix has an excellent CLI and awesome docs. It's stable and plenty usable. All being in one, high-level language like Scheme makes it seem really easy to hack on, and I think that's part of why its CLI is so good already. Nix is faster, it supports macOS, and its package collection is much bigger beca…
What about number of packages available? Does guix have something comparable to Nix Flakes?
Nix flakes are kind of a lot of things: a version pinning system, the switch to pure evaluation mode by default (which impacts caching in a good way but makes configuration slightly more annoying), a distribution mechanism for code written in Nixlang, and a collection of Nixlang schemas which enable a richer command line experience (that, e.g., power the new `nix run` command). It's not clear how many of those functions Nix flakes will retain in its final form.
There's no singular feature that attempts all that in Guix as far as I know, and I don't know the general technical story for evaluation caching with Guix. But Guix does have an integrated, first-party form of package pinning. Where Nix flakes replaces the old 'channel' system, Guix has a richer notion of channels which support pinning in normal Guix expressions.
(In Nix, channels are an output that have a certain structure and get managed in a certain way via fhe nix-channel command to manage them— they're like another type of Nix profile. In Guix, channels are defined by the user directly in Scheme code, just like the rest of their configuratiom, which is more similar to how Nix flake inputs are defined than to Nix channels.)
I've never used Guix channels in anger, so I can't tell you how nice that notion of version pinning is to use.