Guix's use of Guile is fundamentally equivalent to the Nix package manager's use of the Nix language, but the approach Guix takes to organizing packages is very different. IMO, the Nix language approach is cleaner and more elegant when it comes to describing packages, but it's not clear whether that's worth the cost of using a domain-specific language. So, it still remains to be seen what's the best approach.
In Nix the idea of "functional package management" is more visible as there are no packages but functions with arguments that would result in a package once evaluated.
Guix shows that this isn't the only way to do it, but it is a good way.
Lazy evaluation does not have to be a language feature. In the case of Guix's `<package>` record, only some of the fields are delayed or thunked.
I haven't used Guix to be able to compare but it saved my life many times. I suspect the advantage for Guix is that it forces things to be better structured.
Nix is an extremely simple language with quite familiar syntax, a kind of JSON with functions and string interpolation.
Note also that Guix uses Scheme a lot more deeply than Nix uses the Nix language, in the sense that Nix uses e.g. shell scripts where Guix uses Scheme statements. Actual “coding” in the Nix language is relatively rare.
We don't use R7RS in Guix. You need to know about the Scheme syntax, obviously (including keyword arguments), and a couple of common procedures like `string-append`, but aside from that you don't really need to know much about Scheme at all.
What comes in handy is the Guix DSL, which provides a convenient way to specify packages and download origins. Guix also has a bunch of utility procedures that are useful extensions to their Scheme counterparts, such as `mkdir-p` (which does what you think it does) or the `substitute*` form to substitute expressions in a file or list of files.
One important difference between Nix and Guix is that Guix does not glue shell snippets together, but eventually compiles to Guile builder scripts, so it's Scheme all the way down.
I skimmed the paper on "Code Staging in Guix" and I think this should be very doable, but I haven't yet tried Guix for real.
This ability seems like it would have huge implications for system development... I've dabbled with such experiments using Nix, but the lack of hygienic code staging makes it a bit icky.
We don't use systemd but the Shepherd, which is written in Guile Scheme, so system services are indeed written in Scheme and can use Guile libraries. It is a common pattern to define services as the result of procedures taking variables as arguments.
System services in Guix don't have to be limited to Shepherd services. The system service framework in Guix is very flexible and can be used for almost any system setup task, even for mere "activation services" that create directories or files. Services can extend other services:
http://www.gnu.org/software/guix/manual/en/html_node/Service...
I really like nix the package manager and like NixOS the distribution, but learning nix the language was an awful lot of work, and I'm not convinced that it couldn't have been accomplished with a language that is more familiar (Guix demonstrates that baked-in lazy evaluation is not necessary). Even tiny things like "sets" as a name for an associative data type make it just that much harder to learn.
Thank you for the compliment btw.
Ideal would be some DSL that isn't even Turing complete, but that's not practical at the moment. Maybe we'll get there some day.
Makefiles are Turing complete: https://nullprogram.com/blog/2016/04/30/
Here's a good description of why I should care: https://yakking.branchable.com/posts/what-and-why-nix/