4 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 I disagree. YAM
by 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 agoThe 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 agoThat'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.