That being said, I've been working with NixOS recently and it's made me reconsider what is useful for a configuration language. In many reasonably large software projects, where configs become very complex, config reuse (in other words templating or meta-configuration) becomes an increasingly helpful feature. Nix configs are great because it's not just a config, but a full blown purely functional language for manipulating the config. It's intuitive and powerful once you get the hang of it, and I sometimes find myself wishing I could use it when I have to work with yaml, json, etc.
Basically RFC822 email headers, or Debian Control File Format [0] but with "=" instead of ":", and without dedicated comment character.
The biggest problem with this format is that a lot of things are left for the app, so each app will have its own way to implement lists, bools, line wrap support.. Even something like "value override" is left to program implementation. Don't expect YAML/JSON/XML-style automated validators/linters, each program will need its own bespoke parser/generator.
[0] https://www.debian.org/doc/debian-policy/ch-controlfields.ht...
Namely the parsing code.
Checks that might be trivial in OCaml might be utter footguns in say C.
Don't get me wrong here, I get that this is someones spare time project that they might use for themselves only. I am fine with that. But I am unconvinced if the (I admit: well demonstrated) simplicity of the format translates to simplicity of use in the scope it aimed for (replacement for other wide spread configuration formats).
I don't say it is impossible (or even unlikely) that this is an improvement, I just caution against seeing an elegant minimalist approach and automatically assuming it makes things simpler — remember, computers with their binary file systems already have the most simple format that could exist: zero or one. Yet somehow people shot themselves in the foot parsing those for decades. Much of the complexity of computer systems stems from managing the simplicity of the underlying components (if we ignore the thick layer historically grown cruft).
What would it take to change my mind? Elegant examples how to parse all the examples in that post using major programming languages (C, C++, Javascript, Java, Python, Go, Rust, ...). That is ofc a lot of work, but if the format should be adopted that work would be needed anyways.
Take the "fixed point" example, where you have a boolean setting which one file says should should be "yes" and the other says it should be "no" and the language semantics composes that into a list with both values. For what boolean setting does this make sense?
The article says "Overrides are not a problem because you keep both values. And you can decide what to do with them: keep only the first, keep only the last or use some smart logic to combine both of them. You’re the boss."
If you need custom logic in your application determine the setting to use, how is this language helping you?