[kmoser]

Serious question: do people who work with these config files frequently, or on large such files, use simple text editors, or are there "smart" editors that do things like prevent you from making typos or inserting the wrong data type, similar to an HTML form that does basic validation or a DB schema that rejects bad data?

There is no single cure-all, of course, but surely we should be relying on computers to do much of the heavy lifting when it comes to validation and verification of these files, not just as linters after the fact but in realtime while we're editing, and with some sort of knowledge (even if derived programmatically) of what is right and what is wrong so we no longer have to worry about simple footguns.

[kokada]

I think one of the problems of those "configuration languages" is that you can extract semantic information without knowing the target, e.g., with has a specific meaning in GitHub Actions but it is otherwise an unremarkable word in the YAML specification.

But when working with real programming languages it is completely different, you can take semantic information from the current code, and you can have things like types to give you safety.

[JohnMakin]

The problem is most configuration languages are declarative vs imperative like most “real” languages are. You could probably levy the same complaint against declarative languages in general - it’s just a different way of thinking

[kokada]

Nix as used in NixOS is a declarative language and there is none of the issues I cited by being a "real" programming language (or as the article talks about, having "abstractions" like builtin.map). You can pretty easily setup a LSP to get code-completion (even between different projects, like NixOS vs Home-Manager). There is no proper type system in Nix but the module system does supplement it well.