for me? json, yaml, dgaf. Yq works as well as jq.
Yaml is so hard to get right, a misplaced dash or indentation in a list and you're screwed but it's still passable, just does something else than expected. It's not really human readable either, it takes a lot of brainpower (at least for me) to understand what belongs together in a list or how things are grouped together. Much more than for instance xml where it's obvious.
Yaml only barely works, because many editors have added support to help you write k8s config. Otherwise it would be impossible.
Yea, you shouldnt put a lot of logic in your configs. yaml doesnt do that. the tooling does. and templates can be simple and easy to read and DRY principles can put you into traps that make your code harder to maintain than it should be.
Sure, and in the end it's all 1's and 0', but that doesn't seem relevant..
>“Norway” being interpreted as “NO” boolean false is something that sounds very weird to me
Agreed, it's truly weird. YAML tries to be helpful and guess what you meant, a trait that is great in many situations, but not in a config language.
I disagree. YAML can't be transcribed 1:1 to JSON.
Here is an example:
&map: ? {[Complex, key]}
: *map:
And fact introduces context sensitivity (flow vs block, plain vs fold/literal) means its perfs will be kneecapped. I'm aware of high perf json/xml able to read GB/s. Not so for YAML.
Can you give me a practical example of the incompatible data structure you’ve described that isn’t reliant on tooling? I really can’t.
Just because you use it for one page docker conf, doesn't mean someone won't use it for 3000 yaml files that need to load in under ten seconds.
Not to mention complexity of the language will reflect onto complexity of the tooling. The more complex writing tooling is, the less likely someone will write it.
Also I hate the term "human readable". JSON is human readable and editable. Sure you might have problems with editing it, but my work colleague can read binary blobs. That doesn't make them binary blobs human readable.
Also, if the CD process is not too dumb the json validate will find the errors before the file enter production which will save you. At my first company they rewrote our ansible inventory files in json because a yaml uncaught indentation mistake made a firewall open by default, silently.
good:
- a
- b
- c
bad:
- a
- b
- c
Meanwhile, the error in JSON is way more obvious:
{
"good": [
"a",
"b",
"c"
],
"bad": [
"a - b",
"c"
]
}No... 'cause it really depends your data and use case. For me, it's as clear as
"bad": [
"a":[
"b"
],
"c"
]
}But here is the issue: the errors caught in a json-validate won't be in a yaml-validate. If you have 15 inventory file to write per day, you will do a lot of copy pasta, sometimes with errors, and most of those times ansible won't resolve because the yaml was obviously false. The one time it wasn't, it was sadly on a critical part of our infra, and almost cost us a client (and definitely costed trust).
Yaml is way more permissive (because it has more capabilities). But we didn't care about map and semi-code or whatnot. If you need it, more power to you, it just wasn't our original usecase. So they wrote some perl json->yaml interpreter with restricted keywords, and after that, the misalignment risk was negated. Ultimately i arrived at the company, was told the story, then wrote stuff to convert excel->json, then SQL->json, and effectively in the end the extra conversion was unnecessary, and probably harder than just converting directly in yaml. I'm not saying yaml is worse than json, i think in 80% of cases, it's better. I'm just saying that in the rare cases where being correct is way more important than being fast, i'd use json.
Using a restricted subset of both could work, I suppose. But seems a lot of hassle over a minor issue.