Them why not json?

YAML gets cleaners diffs when you edit it.

That's more of a problem with diff tools, though, which like almost all tooling and even programming languages, make the mistake of treating code as plain text.

OK, well, if you want to invent a new VC tool that can parse arbitrary languages into a syntax tree and make a useful diff and then convince everyone to use it instead of git then maybe I’ll stop using YAML.

Semantic Diff tools already exist. Haven't looked at ones that specifically support YAML, but e.g., graphtage claims to do so.

If you want something editable by hand, yaml is much nicer than Json because you get comments and you don't need to worry about missing a bracket.

I have no big love for json or yaml, but i'd gladly take worrying about missing brackets over worrying about the handful of whitespace-related gotchas in yaml.

YAML is way less verbose than JSON. Something as simple as multiline script is terribly suited for JSON.

The problem is when you want to put a script into yaml you should stop and think what it is you’re actually doing.

* JSON doesn't have comments. I could stop right there because that's a total deal-breaker for me for anything that's supposed to be read or written by humans. * JSON doesn't handle multiline strings. * JSON is not especially readable (no structure enforced, braces and double quote mandatory). * JSON can't load YAML but YAML can load JSON.

(lots more)

Given this, I'd much rather XML any day. You can comment using <!-- Comment --> blocks.

I have zero problems with XML. Hard sell though.

It's annoying though because it's so mature compared to everything similar (even YAML, which I obviously quite like); like if you make an XSD for your config files everyone gets free editing features (not just validation, completion as well, even completion of attributes)

No trailing commas makes editing JSON a pain

The lack of trailing commas isn't the problem. The problem is the intermediary commas.

Those are used in JavaScript to give you the option to provide an expression in place of a single term. But that's not even allowed in JSON, so the commas aren't serving any purpose at all.

JSON doesn't support comments.

I don't hate YAML. Who hates YAML?

I didn’t, then I’ve started writing GitHub actions and now I do.

Github actions is fine provided you keep the YAML as short as possible and try to call out to a normal script to do everything - i.e. use it as config.

The problem comes when you try to use it as a programming language in and of itself (which MS encourages because it's a route to vendor lock in). It's a shitty, shitty programming language with shitty debugging tools.

To your first point: yes.

To your second point: yes, yes, and very much yes.

Creating complex release workflows within GHA is hell given the debugging situation and that's what we're using because 'it's there, use it, everyone's using it'. Send help

I do. YAML can return to the rotting hole it's from.

Me and anyone who read https://noyaml.com/ .

So a handful of well-known pitfalls and complaints about how it’s easy to represent the same information differently. Yeah, switching to XML definitely solves that problem.

The fact that you know them doesn't make them any better, it just proves you've got Stockholm Syndrome

I get your point but there is exactly no technology you can use without some known pitfalls, so you pick the one whose pitfalls are the least catastrophic or bothersome to you.

I have literally left a 300k+/yr job, twice, due to having to write and maintain too much yaml.

Templating and significant whitespace is the worst. 10 commits in a row of "error on line 1" until helm finally parses what you want.

I am a software developer with extensive distributed systems experience. I like thinking about systems, not guess-and-check on config templates that become a bespoke DSL with no proper way to debug.

Our config structure requires similar but individualized configs for on-prem and the cloud. These can deviate for the region, the data center, the logical cluster, and at the individual node level for A/B or canary reasons. And of course local dev. You need to have a way to know where the deviations are, like different regional hostnames for services you connect with, different node sizes or replica counts, and different labels, any of which may or may not be correct and will cause an incident if wrong.

Search you yaml PRs, and I bet you will find a commit along the lines of "because yaml."