I'm happy to complain about JSON as a config format as well..

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.

It’s essentially the same data structure under the hood. It’s the interpreters/parsers that are the issue at least in this complaint. “Norway” being interpreted as “NO” boolean false is something that sounds very weird to me, almost to the point of being hyperbole, and I’ve worked with “yaml” (mostly helm and simple configs) for years and dealt with really ridiculous parsing issues. Usually though they’re really easily resolved.

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.

>It’s essentially the same data structure under the hood

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.

> these complaints are misguided. yaml isn’t the problem, it’s whatever the tooling is around it. Yaml is pretty easily transcribed 1:1 to json

I disagree. YAML can't be transcribed 1:1 to JSON.

Here is an example:

    &map: ? {[Complex, key]}
    : *map:

Otherwise Yaml wouldn't be a superset.

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.

The context of this conversation, I think, is in configuration languages - I can’t think of a single reason I’d ever consider performance in that spot. Obviously in data transfer you’re not gonna use gb/sec of yaml, which is why I’ve repeatedly stressed the term “human readable.”

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.

That's not obvious and second, even for configuration it highly depends on the domain. I've seen game engines that used YAML for configuration of in-game entities, where YAML brought its own set of performance misery.

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.

YAML has a lot of quirks. I've written a fair share of YAML config files and I might still prefer it to JSON for that use case. However, JSON is as barebones as it gets and requires zero brain power to read. It's not just tooling, it's a lot less error prone.

to me, json is not easier to read at all, not by a longshot. one innocent missing brace can cause an hour-long rabbithole in a lot of tools. and again, this is an issue of tooling. There’s no way that json’s enforcement of syntax like curley brackets that are easy to confuse with square brackets is easier on the human eyes than indentation based organization like python/yaml, but, people should use whatever’s easiest for them. I just struggle to believe most people naturally find json more readable.

I think you have like a dozen of available json-validate tools, and even dumb ones can find a missing curly brace (dome will even propose you lines where you can add it).

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.

I disagree:

    good:
      - a
      - b
      - c

    bad:
      - a
        - b
      - c

Obviously when I show you this, it's clear that b is incorrectly indented, but in a real file, this can be a nightmare to figure out. Particularly if the entries are nested, or tab characters are involved.

Meanwhile, the error in JSON is way more obvious:

    {
      "good": [
        "a",
        "b",
        "c"
      ],
      "bad": [
        "a - b",
        "c"
      ]
    }

> Obviously when I show you this, it's clear that b is incorrectly indented,

No... 'cause it really depends your data and use case. For me, it's as clear as

      "bad": [
        "a":[
          "b"
        ],
        "c"
      ]
    }

Sure, but the difference in json is very clear,and in yaml it's not.

Not really, i think yaml have more capability, you can convert json to yaml 1:1, but the reverse isn't true.

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.

Makes me wonder if a kind of meta-format for config would be useful. Like, this is the internal data structure, you provide the mapping from whatever config format you like. People would then be free to open the config in whatever format pleases them. The project maintainer might have arbitrarily picked YAML, but your editor seemlessly opens it as TOML, for example.

Not all concepts from YAML map 1-to-1 to TOML, and vice versa, so this won't really work as it's a lossy process.

Using a restricted subset of both could work, I suppose. But seems a lot of hassle over a minor issue.