An interesting advantage of Guix over Nix is having better options for runtime isolation. Nix is not well developed in this area yet, although one can always use bwrap or AppArmor to implement something ad hoc.
Besides, Guix uses Scheme everywhere, whereas Nix is a mix of the Nix language and lots of shell code. The Nix language is a pretty elegant lazy functional language, and yields very compact and clean code. But if you want to do complex things, Scheme might be easier.
Although it doesn't seem have much in the way of runtime isolation of Guix source files themselves. From what I can tell it runs the Guile scripts that evaluate to manifests and such as your own user, with all of the authority associated with that.
So although Guix provides good mechanisms for isolating applications at runtime, you do have to put a lot of trust in the channels you're using.
(This is something I would like to see improved as a Guix user.)
Thanks. So there are two concepts where isolation is mentioned, the --pure and the --container options. But still the documentation is very light on details and doesn't really answer what kind of (if any) security boundary or sandbox is provided by the container feature.
How might it compare to eg using nsjail[1] or firecracker [2] or flatpak's sandbox[3]? These could be also good benchmarks for the documentation.
Good point. My main distro is NixOS, so I am not too familiar with Guix. After a quick glance at the code, Guix seems to be similar to bwrap et al. as it uses kernel namespaces for sandboxing [1].
I think the pure option is not really for (security) sandboxing, but rather for making sure your programs do not use any dependencies that are not explicitly declared, i.e. to ensure referential transparency.
Besides, Guix uses Scheme everywhere, whereas Nix is a mix of the Nix language and lots of shell code. The Nix language is a pretty elegant lazy functional language, and yields very compact and clean code. But if you want to do complex things, Scheme might be easier.