{
start: makeForkexecConstructor(["…/bin/ntpd", "-n", "-c", "/…/…-ntpd.conf", "-u", "ntpd", "-g"]),
logFile: "/var/log/ntpd.log"
}
And I think it's also hard to claim that one is better than the other. I personally have gotten my feet wet with Guix and I would love the time to become more familiar it.
The systemd variant uses one of the universal DSLs for key-value pairs (key=value) and the universal DSL for calling programs (program name, space separated list of arguments).
The latter is even the same syntax that lisp uses for functions calls – thus I would argue the systemd config file looks more like a lisp program than the Guix version does.
As a person that has seen a reasonable amount of sexpression, this is what I would not bat an eye at:
(start /path/to/ntpd -n -c /etc/ntpd.conf -u ntpd -g)
If so, I fully agree, on the config being less powerful.
Maybe let me add to my original argument, because it does not seem to make it’s point well.
I think that it would be feasible (and worthwhile) to simplify the configuration structure while keeping Guile syntax, and have the complaint be a non issue. As opposed to keeping the semantic structure and just changing the syntax as the comment I replied to proposed.
Yeah, don't do that. Both the program name, and the arguments can and do contain spaces. Do instead what every other languages do, that is, use a list of strings to invoke programs.
> The latter is even the same syntax that lisp uses for functions calls
No it's not.
Choosing space for a very common thing in your language often makes sense, as you reduce the amount of visual elements. Thus space is often used to apply arguments to functions. Lisp and Haskell are common examples Though, you could argue that in Lisp it only is an application if it is within parenthesis.
So (ls -l .foo) is a three element list of symbols in Common Lisp or Scheme, sure.
Symbols are not strings though; we don't necessarily want to use symbols this way. For one thing, they get interned. That means they stick around forever, or until explicitly uninterned. The symbols are memorized so that the next time they appear, the same object is returned (almost always implemented as a pointer to the same symbol).
String tokens use mandatory double quotes: ("ls" "-l" ".foo")
And programming languages that have variables, string type, and function calls do the opposite. In C, Python, JavaScript etc, in order to start a program you make a function call with a list of strings.
> Choosing space for a very common thing in your language often makes sense,
Not interpreting space separated things as strings but as keywords (built ins, variable names, literals) makes more sense for bigger programs.
Having the shell taken out of the equation is what Lennart promised but never delivered.
I don't know lisp, but the idea of having each argument be part of a list (kind of like launchd's xml format) resonates with me.
> the actual guile scheme documentation didn't seem to explain that syntax at all
It does, here: https://www.gnu.org/software/guile/manual/html_node/Expressi...
It's a basic concept of Lisp. Everything is evaluated, unless quoted. Code is data is code!
Which nowadays is 'yaml is code is yaml is code is yaml' in the devops world. The wheel turns.
(quote data)
'data
'x ⇒ x
'(1 2 3) ⇒ (1 2 3)
'#(1 (2 3) 4) ⇒ #(1 (2 3) 4)
(quote x) ⇒ x
(quote (1 2 3)) ⇒ (1 2 3)
(quote #(1 (2 3) 4)) ⇒ #(1 (2 3) 4)
— <https://www.gnu.org/software/guile/manual/html_node/Expressi...>
Systemd has done things that previously were trivial very difficult. I would like to know how it fares in that arena. The syntax can just be learned.
NM, answered my own question. It’s literally Scheme.
I actually know the answer to that one!
> The principal lesson of Emacs is that a language for extensions should not be a mere "extension language". It should be a real programming language, designed for writing and maintaining substantial programs. Because people will want to do that!
> Another lesson from Emacs is that the way to make sure an extension facility is really flexible is to use it to write a large portion of the ordinary released system. If you try to do that with Tcl, you will encounter its limitations.
> Tcl was not designed to be a serious programming language. It was designed to be a "scripting language", on the assumption that a "scripting language" need not try to be a real programming language. So Tcl doesn't have the capabilities of one. It lacks arrays; it lacks structures from which you can make linked lists. It fakes having numbers, which works, but has to be slow.
From Why you should not use Tcl by Richard Stallman [1].
I don't see more or fewer issues, but I also don't see the value to using Scheme instead of a conf. file like format.
At the end, there's talk about adding the possibility to live reconfigure services, which is pretty cool but I don't really see what kind of users are targeted by that use-case, at least not regular users like me who's running Linux on a single laptop.
The link at the end (https://spritely.institute/news/spritely-nlnet-grants-decemb...) is IMO much more interesting since it would make it possible to orchestrate several machines and their services as well. If you have live reloading as well, I think it would make for good developer experience.
My main gripe with Guile is its ergonomics and tooling: no LSP, no linter, no step-debugger that I know of and the docs are often unhelpful imo.
Maybe I'm not Scheme brained enough but I think it's a shame because there are some really cool projects out there (anything https://spritely.institute/ really).
P.S: I know that some people will tell me to get used to REPL based development which I think is fine for small-ish projects but I can't understand the flow one uses for larger projects where many components might need to talk to each other.
But some of Shepherd's strengths are in other examples, and it makes sense to evaluate the whole.
A few examples:
* if we want multiple similar services, I'd prefer writing a Guile function than using systemd templates.
* the above Shepherd guile code lives lexically alongside your wider Guix guile code. AST-aware syntax highlighting and refactoring tools would treat them the same. That's pretty neat and beats having two different languages. Guix calls this g-expressions.
This "one language for all your system" is pretty compelling, but Guix's feature set is a bit too far behind NixOS at the moment for me.
I would be using nonGuix if it booted on my machine (libre seemingly has its claws too deep), instead of Nix, precisely because Guix has far less NIH: Nix is homegrown everything. Guile was a pre-existing project (for both Guix and The Shepherd), for a pre-existing language family.
'("…/bin/ntpd"
"-n" "-c" "/…/…-ntpd.conf"
"-u" "ntpd" "-g")
I don't want to worry about list versus quote in a configuration language, because they shouldn't be evaluation going on, or not by default.
e.g. instead of systemd's simple:
We have this mess: They say you don't need to be an expert on guile scheme to build a service file, but it does seem as though you need to know things like what `'(ntpd)` means, which I assumed was some kind of identifier literal, and it seems to be what's called a 'data literal' in scheme, but I had to google to discover that since the actual guile scheme documentation didn't seem to explain that syntax at all.I get that there are benefits to being able to do more advanced scripting in a service file, but this seems like a classic example of programmers writing things for programmers and not for users (or at least, not for users who don't 'get it').
Going to chalk this up as another 'GNU reimplemented something badly because of NIH syndrome' incident and move on.