> the problem is that YAML covers so many edge cases with different parsing operators that it becomes a bit of a cryptic mess trying to remember which operate is needed when.
This was exactly my point around multi-line strings. You look at a mess of >'s and |'s and it's absolutely not intuitive which one you should use if the configuration files for one of the languages you're required to use happens to use YAML. In json, there's virtually no ambiguity. Everything's either a string, a number or a bool or a struct, and they all have exactly the same shape with ... really no options to make things "easier"
As for structs and arrays, YAML doesn't really make them clear, in my opinion, due to its lack of opening and closing values.
So, if you're new to k8s and need to make a configuration change to something because the darn thing doesn't work, you're forced to learn yet another markup language when it could just be a very familiar and comparatively intuitive json blob.
For example,
options:
- key: value
foo: bar
thing: thing2
smell: apple
"Oh, so to fix this, I just need to add another entry to turn on the debug flag? And it's 'debug: true'? Oh, okay, so that's ...
options:
- key: value
foo: bar
thing: thing2
smell: apple
debug: true
right?
Oh, no? It's not... well what is it?
And then a long conversation with a coworker later, they explain, "Oh! No no no, it's this:"
item:
- key: value
foo: bar
thing: thing2
smell: apple
- key: value2
debug: true
Turns out debug was another option you needed to add.
Or, in other places in some syntax, you see a bunch of:
items:
- entry
- entry2
- entry3
or
item: 1
item2: 2
item3: 3
I've familiarized myself more with YAML over time; but, its learning curve is substantially more difficult than:
{
"everything is inside curly brackets": "keys and values can be strings",
"there's a comma at the end of everything: [
"arrays exist",
"they're also comma delimited",
1, "types don't matter"
]
}
To be honest I much much prefer YAML for manually handling multiline strings. And frankly JSON's strictness on commas after all except the final entry catches me out so many times (it doesn't help that most parsers aren't great at pointing out where the missing comma is).
Being pragmatic, I'd say neither serialisation format is better than the other. JSON does something things better (It's easier to grok nested structures and simpler to reason about the specification) but YAML does other things better (easier to embed multiline blocks of text, handles streaming better, supports comments).
Let's not also forget that most of the stuff that people dismiss in JSON is only solved by unofficial hacks (eg jsonlines) that might be widely supported but you cannot rely upon universally. So then you have two problems: a standard that doesn't support x and multiple different implementations that don't strictly support the standard. YAML is a hell of a lot better when it comes to removing undefined behaviour in parsers -- even if that does come at a cost to the complexity of the specification.
This was exactly my point around multi-line strings. You look at a mess of >'s and |'s and it's absolutely not intuitive which one you should use if the configuration files for one of the languages you're required to use happens to use YAML. In json, there's virtually no ambiguity. Everything's either a string, a number or a bool or a struct, and they all have exactly the same shape with ... really no options to make things "easier"
As for structs and arrays, YAML doesn't really make them clear, in my opinion, due to its lack of opening and closing values.
So, if you're new to k8s and need to make a configuration change to something because the darn thing doesn't work, you're forced to learn yet another markup language when it could just be a very familiar and comparatively intuitive json blob.
For example,
"Oh, so to fix this, I just need to add another entry to turn on the debug flag? And it's 'debug: true'? Oh, okay, so that's ... right?Oh, no? It's not... well what is it?
And then a long conversation with a coworker later, they explain, "Oh! No no no, it's this:"
Turns out debug was another option you needed to add.Or, in other places in some syntax, you see a bunch of:
or I've familiarized myself more with YAML over time; but, its learning curve is substantially more difficult than: