You're currently being downvoted, but I agree, YAML is kinda terrible, not sure why anyone thought Python's syntactically relevant whitespace was ideal for a config file.

Classic example:

  - containerPort: 7173
    name: http

I think that's an object in a list? But it's not overly clear.And if I indented any of those lines wrong...

>not sure why anyone thought Python's syntactically relevant whitespace was ideal for a config file.

Because it reduces syntactic noise and increases informational density.

Most other serialization formats end up putting in indentation anyway to make them readable (JSON, TOML).

Don't forget the plethora of truthy values that put Javascript to shame.

   - country: NO

Of course it's boolean

that was changed in YAML 1.2[0], which I think is many years old, but people don't specify a version on config files anyway and I'm not even sure most parsers respect it, so it keeps popping up, which is sad.

[0] https://yaml.org/spec/1.2/spec.html#id2803629

That's the problem with bad formats: they live forever. They and any number of parsers for any version between version 0 and now.

That's a map as a list element, iirc the terminology. But check out this.

When studying the Yaml spec I discovered that a map property (key: value) can have not only a string as its key, but any value. Even a list. (cue screams)

Here's another reason why YAML is bad:

the fact that I have to read the spec to figure out what's going on.

It should have been fairly simple to do this.

Why do I have to know the difference between ":" and "=" ...?

Why didn't anyone learn from CSS when we all made pre-processors like stylus, less and sass that added white-space sensitivity. It's not great.

I thought HCL was one of the best attempts at a terse config language. Shortening foo { bar { bazz {} }} to foo bar baz{} cleans up plenty.

also, keywords of the underlying software mechanisms are decoupled, so uncheckable for plain YAML tooling. Whereas with XML you can at least infer a lot about the desired structure and keywords from the schema. Deeper checks are only possible with "real" programming languages, preferrably statically typed ones. I'm wondering when that wisdom trickles down to configuration languages.

YAML is unusable without a sufficiently capable linter. Syntax is very fragile and completely decoupled from function.

You're partially kidding but you're 100% right.

Someone in another thread mentioned using some LISP or LISP-like language to solve this problem.

Would something like TOML make things better here?

What would have been the solution?

Dhall is an example of a configuration language. Its programs must terminate. It aims for safety, claiming that it can support safe evaluation of untrusted code. https://dhall-lang.org/

TBH, I have no experience with it. But, it sounds like if you need a configuration language with programmatic features, it would be more suited to the job than a general purpose programming language.

XML, but I guess I won't get many friends for asserting that.

I really regret disliking XML all those years ago, now that I've seen the alternative.

Nope. Json has schema validation too, and every language has a json parser

JSON doesn't do comments.

Not officially, but it's fakeable

Which for me is a design smell, why bother with workarounds when XML already offers me all the best tooling out of the box.

For me, xml is just too much, and when working with C or C++ (not t sure about rust) it's just a pain. Can your json schema file not serve as the documentation?

Why should it be a pain? Parsing XML is no different than parsing JSON, there are plenty of robust parsers available since around 2000.

Mature libraries with plenty of experience deploying into production.

Plus for small enough stuff, like configuration files, one can just plug XPATH as well, making the search for items even easier.

If something like k8s implemented comments as specific comment fields that would actually be pretty useful. The fields could be parsed and show in GUIs.

That is the workaround, just add it as "comment":"comment text". Having one comment for each field in an object would get unwieldy though. Anther place for them is possibly in the json schema file.

Then use HTML and extend the functionality with JSX

Useless work when XML already has all the tooling available and battle tested in production.