News for hackers. Stuff that matters.
Re:How CUE wins by skybrian on Tuesday August 10, 2021 @12:22PM (#28130752)
I’m not sure that CUE or any similar system can fix the essential reasons that configuration languages become hard to use.

A big problem with configuration parameters is understanding what they do. Typically you depend on the documentation and experimentation, which is okay for a text editor but more difficult when software gets more complex and abstract.

To find out what a function does, you can read its definition. But the meaning of a constant or a configuration parameter doesn’t come from its definition. It comes from the code that uses it. Typically, it could be used anywhere in the program, and the code could be of arbitrary complexity.

But users typically don’t read the source code at all, so basically you’re tweaking a global variable and you hope it does what you think.

Configuration files are written in little languages where each parameter has potentially global effect and the interactions between them is usually unspecified. We hope they’re orthogonal, but this depends on the good taste of the language designer. When constants get turned into configuration parameters on an ad-hoc basis, this language is unlikely to be designed well.

Re:How CUE wins by fanf2 on Tuesday August 10, 2021 @12:39PM (#28130993)
What I wanted from Cue was a way to set structured config parameters in one place (eg, my server roles, host names, and IP addresses) and populate the various config files that need that information, with a bit more typefulness than yaml and jinja.

[I look after DNS servers so the setup is relatively static, but I would like to make it a lot easier to spin up temporary test instances, which needs a more loosely coupled config setup.]