4 ms·

There is no problem with YAML, just like there was no problem with XML at all. The problem is with the software devs who use it for the wrong thing. I just wond

There is no problem with YAML, just like there was no problem with XML at all. The problem is with the software devs who use it for the wrong thing. I just wonder why JSON doesn't get all the hate, while it is a terrible format also: it is not streamable (YAML is), it doesn't have comments... and non-standard workarounds are used for these features. Norway better than YAML, in my opinion.

_ink_ 2mo ago
There are plenty of problems with YAML as the article shows. The biggest problem with YAML is, that serializer and deserializer need to agree on rules outside of the spec, because otherwise they can be both compliant and still don't understand each other.
- riffraff 2mo ago
  isn't this true for most formats? You'd use a string to encode a date or version in JSON just like you would in YAML[0]. Either you have an infinite spec, or you always have things outside it. [0] YAML would allows you to tag the type, but nobody does it anyway
Diti 2mo ago
I also wonder why it’s the 2012 version of the language which gets all the hate, instead of the hate being directed at Google, who doesn’t care about putting resources towards updating the main offender, Kubernetes’ YAML 1.1 parser. https://github.com/kubernetes/kubernetes/issues/34146#issuecomment-252692024 https://github.com/kubernetes/kubernetes/issues/34146#issuec...
- 21asdffdsa12 2mo ago
  Would totally love to do that bro, is not a resource or finance problem- not even talent - AI could probably do it with oversight .. but No Promo.. cant touch it once another guy declared it complete.. that s them rules.
- ishouldnotbutk8 2mo ago
  Wouldn't this be a backwards compatibility nightmare? All of the unexpected parses from this blog post suddenly change behaviour? Google put forward KYAML recently (https://www.kubernetes.dev/resources/keps/5295/ https://www.kubernetes.dev/resources/keps/5295/), it looks like a more sane way forward.
mogoh 2mo ago
I, for one, hate JSON.
einpoklum 2mo ago
> Norway better than YAML, in my opinion. I agree that Norway is better than YAML. Let's keep Norway and dump YAML. > There is no problem with YAML I am reminded of: "There are no American infidels in Baghdad. Never!"
dghf 2mo ago
YAML is (or at least, is declared by its maintainers to be) a superset of JSON, making any JSON document also a valid YAML document. So surely if YAML is streamable, JSON must be too? Or are the YAML maintainers incorrect?
- vkazanov 2mo ago
  Yaml streams are just yaml docs separated by "---" withing a single file. The json spec just doesnt do anything like that but jsonl does.
- boricj 2mo ago
  I wrote a C++ library at work that, among other things, serializes/deserializes to JSON, CBOR and BSON. I don't get that point. The first two formats I've implemented as fully streaming, the serializers emit into an output iterator one character/byte at a time and the deserializers only need to hold one value at a time (mostly for strings, and not even for CBOR's byte arrays, which are streamed). BSON requires full document instantiation because of byte offsets and is genuinely anti-streaming in its design. I happen to have implemented a serializer for YAML, fully streaming, mostly as a compact-ish human-readable debug data representation. I can scarcely think of fates worse than having to write a spec-compliant YAML parser.
- fodkodrasz 2mo ago
  > YAML is (or at least, is declared by its maintainers to be) a superset of JSON, making any JSON document also a valid YAML document. > So surely if YAML is streamable, JSON must be too? Given YAML is not a subset, but a superset of JSON, as you correctly noted, I'm not sure how you reached that conclusion. > Or are the YAML maintainers incorrect? I think you should check this page before making snarky comments: https://en.wikipedia.org/wiki/Superset https://en.wikipedia.org/wiki/Superset See also the comment below: https://news.ycombinator.com/item?id=49476489 https://news.ycombinator.com/item?id=49476489 Offtopic note: I wanted to dig the wiki superset link up the lazy way, so searched for superset, and all I got was endless list of marketing trash links. Even on DDG. RIP, we are on the Dead Internet.
  - 2mo ago
hatthew 2mo ago
I find json annoying to write a lot of the time, but I do enjoy that it's a lot more difficult to get wrong than yaml. The json spec is pretty clear, and can be learned and memorized by any programmer in 5 minutes. I'd much rather write in a format that's slightly annoying than a format that's slightly ambiguous.
vkazanov 2mo ago
There numerous problems with YAML. It is underdefined, ambiguous, fragile, and is just impossible to write a portable parser for. JSON is naive, lacks almost everything. But is supereasy to parse and read. As funny as it sounds, XML is overspecified. Parsing is possible and predictable but supporting the full standard (all of them) is so much work that nobody does it anyway. So, given the choice above, i'd go for naive simplicity.
- DanielHB 2mo ago
  There is a subset of yaml which is like 99.9% of all yaml code that is fine. And then you have whatever the hell OpenAPI uses.
  - vkazanov 2mo ago
    Yes, true, there is this legendary subset... but parsing even a sane subset of the spec is a nightmare for all parties involved.
- preg_match 2mo ago
  XML being overspec'd is good, IMO, because we get things like xpath, XLSX, schemas, etc very easily. It would be fine if people just use libraries for these. I mean, I certainly wouldn't roll a JSON parser by hand either, even if it is easier. XML just looks nasty, but IMO not worse than JSON. JSON is not easy to read, because brackets suck for deep nesting. XML nesting is 100x easier to read, because the closing tags tell you exactly what is closing.
  - vkazanov 1mo ago
    Sure, a careful spec is always great. In xml's they clearly overdid it. all the formats/substandards you listed... there is just not a single library that supports all of the standard. And because implementations are so different, most users just stick to a single C library. That library, btw, is also incomplete and undermaintained. So that's the problem with complex standards: they are hard to implement and support. Nobody does this, unless it is a business-critical matter.
throw0101a 2mo ago
> I just wonder why JSON doesn't get all the hate, while it is a terrible format also: […] it doesn't have comments […] The lack of comments in JSON is not a bug; comments in JSON were an anti-feature. Douglas Crockford intentionally removed them to prevent developers from using comments to store parsing directives (which he saw people doing in earlier revisions). * https://web.archive.org/web/20120507093915/https://plus.google.com/118095276221607585885/posts/RK8qyGVaGSr https://web.archive.org/web/20120507093915/https://plus.goog... * 2012: https://news.ycombinator.com/item?id=3912149 https://news.ycombinator.com/item?id=3912149
- fluffybucktsnek 2mo ago
  I'd say that only really strengthens OP's overall point of being about using "the wrong language for the wrong thing".
  - throw0101a 2mo ago
    Yes: JSON was meant to be a machine-to-machine format, and it's the humans that are insisting on comments.
    - krapp 2mo ago
      JSON was also meant to be read and edited by people, as was all web technology, and people have a use for comments. Even Douglas Crockford suggested that people could still use comments, as long as they strip them out before parsing.
NuclearPM 2mo ago
What is Norway? Couldn’t find a reference to it.
- bulatb 2mo ago
  I think they meant "no way," but maybe it's a joke about the Norway problem? YAML famously confuses Norway's country code ("NO" or "no" without quotes) with unquoted "no" meaning Boolean false.
patrickthebold 2mo ago
What do you mean that JSON is not "streamable"? There are things like https://www.baeldung.com/jackson-streaming-api https://www.baeldung.com/jackson-streaming-api but maybe there's more in you definition of "streamable" that JSON doesn't satisfy.

_ink_ 2mo ago

There are plenty of problems with YAML as the article shows. The biggest problem with YAML is, that serializer and deserializer need to agree on rules outside of the spec, because otherwise they can be both compliant and still don't understand each other.

riffraff 2mo ago
isn't this true for most formats? You'd use a string to encode a date or version in JSON just like you would in YAML[0]. Either you have an infinite spec, or you always have things outside it. [0] YAML would allows you to tag the type, but nobody does it anyway

Diti 2mo ago

I also wonder why it’s the 2012 version of the language which gets all the hate, instead of the hate being directed at Google, who doesn’t care about putting resources towards updating the main offender, Kubernetes’ YAML 1.1 parser. https://github.com/kubernetes/kubernetes/issues/34146#issuecomment-252692024 https://github.com/kubernetes/kubernetes/issues/34146#issuec...

21asdffdsa12 2mo ago
Would totally love to do that bro, is not a resource or finance problem- not even talent - AI could probably do it with oversight .. but No Promo.. cant touch it once another guy declared it complete.. that s them rules.
ishouldnotbutk8 2mo ago
Wouldn't this be a backwards compatibility nightmare? All of the unexpected parses from this blog post suddenly change behaviour? Google put forward KYAML recently (https://www.kubernetes.dev/resources/keps/5295/ https://www.kubernetes.dev/resources/keps/5295/), it looks like a more sane way forward.

mogoh 2mo ago

I, for one, hate JSON.

einpoklum 2mo ago

> Norway better than YAML, in my opinion. I agree that Norway is better than YAML. Let's keep Norway and dump YAML. > There is no problem with YAML I am reminded of: "There are no American infidels in Baghdad. Never!"

dghf 2mo ago

YAML is (or at least, is declared by its maintainers to be) a superset of JSON, making any JSON document also a valid YAML document. So surely if YAML is streamable, JSON must be too? Or are the YAML maintainers incorrect?

vkazanov 2mo ago
Yaml streams are just yaml docs separated by "---" withing a single file. The json spec just doesnt do anything like that but jsonl does.
boricj 2mo ago
I wrote a C++ library at work that, among other things, serializes/deserializes to JSON, CBOR and BSON. I don't get that point. The first two formats I've implemented as fully streaming, the serializers emit into an output iterator one character/byte at a time and the deserializers only need to hold one value at a time (mostly for strings, and not even for CBOR's byte arrays, which are streamed). BSON requires full document instantiation because of byte offsets and is genuinely anti-streaming in its design. I happen to have implemented a serializer for YAML, fully streaming, mostly as a compact-ish human-readable debug data representation. I can scarcely think of fates worse than having to write a spec-compliant YAML parser.
fodkodrasz 2mo ago
> YAML is (or at least, is declared by its maintainers to be) a superset of JSON, making any JSON document also a valid YAML document. > So surely if YAML is streamable, JSON must be too? Given YAML is not a subset, but a superset of JSON, as you correctly noted, I'm not sure how you reached that conclusion. > Or are the YAML maintainers incorrect? I think you should check this page before making snarky comments: https://en.wikipedia.org/wiki/Superset https://en.wikipedia.org/wiki/Superset See also the comment below: https://news.ycombinator.com/item?id=49476489 https://news.ycombinator.com/item?id=49476489 Offtopic note: I wanted to dig the wiki superset link up the lazy way, so searched for superset, and all I got was endless list of marketing trash links. Even on DDG. RIP, we are on the Dead Internet.
- 2mo ago

hatthew 2mo ago

I find json annoying to write a lot of the time, but I do enjoy that it's a lot more difficult to get wrong than yaml. The json spec is pretty clear, and can be learned and memorized by any programmer in 5 minutes. I'd much rather write in a format that's slightly annoying than a format that's slightly ambiguous.

vkazanov 2mo ago

There numerous problems with YAML. It is underdefined, ambiguous, fragile, and is just impossible to write a portable parser for. JSON is naive, lacks almost everything. But is supereasy to parse and read. As funny as it sounds, XML is overspecified. Parsing is possible and predictable but supporting the full standard (all of them) is so much work that nobody does it anyway. So, given the choice above, i'd go for naive simplicity.

DanielHB 2mo ago
There is a subset of yaml which is like 99.9% of all yaml code that is fine. And then you have whatever the hell OpenAPI uses.
- vkazanov 2mo ago
  Yes, true, there is this legendary subset... but parsing even a sane subset of the spec is a nightmare for all parties involved.
preg_match 2mo ago
XML being overspec'd is good, IMO, because we get things like xpath, XLSX, schemas, etc very easily. It would be fine if people just use libraries for these. I mean, I certainly wouldn't roll a JSON parser by hand either, even if it is easier. XML just looks nasty, but IMO not worse than JSON. JSON is not easy to read, because brackets suck for deep nesting. XML nesting is 100x easier to read, because the closing tags tell you exactly what is closing.
- vkazanov 1mo ago
  Sure, a careful spec is always great. In xml's they clearly overdid it. all the formats/substandards you listed... there is just not a single library that supports all of the standard. And because implementations are so different, most users just stick to a single C library. That library, btw, is also incomplete and undermaintained. So that's the problem with complex standards: they are hard to implement and support. Nobody does this, unless it is a business-critical matter.

throw0101a 2mo ago

> I just wonder why JSON doesn't get all the hate, while it is a terrible format also: […] it doesn't have comments […] The lack of comments in JSON is not a bug; comments in JSON were an anti-feature. Douglas Crockford intentionally removed them to prevent developers from using comments to store parsing directives (which he saw people doing in earlier revisions). * https://web.archive.org/web/20120507093915/https://plus.google.com/118095276221607585885/posts/RK8qyGVaGSr https://web.archive.org/web/20120507093915/https://plus.goog... * 2012: https://news.ycombinator.com/item?id=3912149 https://news.ycombinator.com/item?id=3912149

fluffybucktsnek 2mo ago
I'd say that only really strengthens OP's overall point of being about using "the wrong language for the wrong thing".
- throw0101a 2mo ago
  Yes: JSON was meant to be a machine-to-machine format, and it's the humans that are insisting on comments.
  - krapp 2mo ago
    JSON was also meant to be read and edited by people, as was all web technology, and people have a use for comments. Even Douglas Crockford suggested that people could still use comments, as long as they strip them out before parsing.

NuclearPM 2mo ago

What is Norway? Couldn’t find a reference to it.

bulatb 2mo ago
I think they meant "no way," but maybe it's a joke about the Norway problem? YAML famously confuses Norway's country code ("NO" or "no" without quotes) with unquoted "no" meaning Boolean false.

patrickthebold 2mo ago

What do you mean that JSON is not "streamable"? There are things like https://www.baeldung.com/jackson-streaming-api https://www.baeldung.com/jackson-streaming-api but maybe there's more in you definition of "streamable" that JSON doesn't satisfy.