Hello,
just FTR, i don't think that the guix codebase is too bad in this regard.
It's not bad for the slightly initiated, which does still take time, and I think that front would perhaps benefit from some attention.
My main take away from this was that what I liked mostly about the BeaverLabs syntax was how short and simple minimalist systems became and that larger intentions could be represented by short invocations. The thing is services already allow that. There's os/git a beautiful function in BeaverLabs, which calls a set of other beaverlabs functions but it could equivalently be a service which extends other services. Perhaps this implies that what is wished for is a set of convenience services that combine sets of higher-level features, and making the operating-system record itself friendlier to specifying very little. I did mention observations about the functional approach here, but after a while of using it, I myself in the end failed to see its merits apart from the slightly shorter service declaration which I personally recovered by a trivial (&s #NAME# #BODY# ...) => (service #NAME#-service-type (#NAME#-configuration #BODY# ...)) replacement, without the need for all the extra effort. I agree with the points made by others about grepability and approachability. Perhaps though BeaverLabs service syntax could deserve a mention as an alternative syntax somewhere in the cookbook or as an appendix in the manual/blogpost to show how malleable guix is. Cheers
