You can use nix alongside guix, it’ll just double-up the dependencies on disk:
services (append (list (service nix-service-type))
%base-services)))
Services are, in guix terms, any configuration change to a computer, so creating your own service 99% of the time is just extending etc-service-type
and creating a variable interface to fill in the config file text yourself
Creating a service as in a daemon of some kind uses shepherd and involves extending shepherd-service-type
or home-shepherd-service-type
with your service description, depending on whether the service runs in root or user space.
Shepherd service configurations aren’t actually part of the guix spec(https://www.gnu.org/software/shepherd/manual/shepherd.html#Defining-Services), but still use Guile, so you can interoperate them super easily.
It’s important in guix to understand lisp pretty thoroughly, and knowing how to program lisp is still a very useful skill to have so I’d recommend learning it even if you never touch guix.
Main issue is drivers. One of the best places to take advantage of rust’s memory safety is in hardware drivers, and those would be hard to share between separate kernels.
That entire talk, and the complaint that Ts’o responded to was that to continue with rust, there needs to be some responsibility from the guys working on the underlying C bindings to not break downstream dependencies if they refactor code.
The answer from some of the Kernel developers, and vocally by Ts’o was: lol no fuck you and your toy language.