5 ms·

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, these same people

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, these same people will never complain about json because the tooling around it is better. Yet, yaml is usually easier for me as a devops/SRE person to work with because it is more human readable than json and super great tools like helm use it almost exclusively. for me? json, yaml, dgaf. Yq works as well as jq.

globular-toast 3y ago
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.
- arp242 3y ago
  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.
matsemann 3y ago
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.
- JohnMakin 3y ago
  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.
  - kristiandupont 3y ago
    >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.
eknkc 3y ago
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.
- JohnMakin 3y ago
  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.
  - orwin 3y ago
    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.
    - JohnMakin 3y ago
      but, again, there is nothing specific to json that makes this better than is not present in yaml. yaml/json can convert 1:1.
      - maccard 3y ago
        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" ] }
Ygg2 3y ago
> 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.
- JohnMakin 3y ago
  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.
  - Ygg2 3y ago
    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.

globular-toast 3y ago

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.

arp242 3y ago
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.

matsemann 3y ago

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.

JohnMakin 3y ago
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.
- kristiandupont 3y ago
  >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.

eknkc 3y ago

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.

JohnMakin 3y ago
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.
- orwin 3y ago
  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.
  - JohnMakin 3y ago
    but, again, there is nothing specific to json that makes this better than is not present in yaml. yaml/json can convert 1:1.
    - maccard 3y ago
      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" ] }

Ygg2 3y ago

> 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.

JohnMakin 3y ago
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.
- Ygg2 3y ago
  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.