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.
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#issuec...
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.
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.
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.
> 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).
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.
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.
> 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.
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.
The "streamed JSON" needs --- line sparators, which is not a JSON spec feature, thus that data stream is valid YAML from that point, bot not a valid JSON stream.
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.
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.
Surprised TOML didn't get mentioned in the alternatives section, it's probably my favourite configuration format.
I'm working on a project now that uses YAML for configuration (it makes more sense in this context than TOML) and am parsing it using Rust's `serde` crate (via `serde_norway`). It's not so bad if you use `#[serde(deny_unknown_fields)]` everywhere.
My usage of YAML has been limited. For the times I have used it (kubenetes, docker compose, other things, etc) -- I don't get what it so special about it.
It just seems reinventing the wheel again and again.
I am not suggesting JSON is perfect, either. However I do prefer it to YAML (and XML) by a mile.
It's a shame s-expressions never taken off.
(select (id name)
(:from users)
(:where (= name "Peter")))
- "something broke" is way better than stack traces with line numbers
That sums it up. Its the same since the days of XML. Someone decides to make something configurable externally and then everything gets put in there for convenience. Now we are programming in XML/YAML without even a stack trace (or a debugger, or call hierarchy, or type checking or ... )
You really should not blame it on YAML that if you put a random hash value in a field that it may be a number. Like, duh. If you want a string, use quotes.
I think KYAML[1] is very relevant here. KYAML is a strict subset of yaml[2], supported natively by kubernetes tooling in most recent versions.
In my opinion it's closer to JSON with comments than to YAML, but overall it looks like a pretty nice format, that solves some of pain points of both technologies. This is not the first nor the only JSON-with-comments format, so I wonder if it manages to break out of kubernetes world and become popular.
Modern editors make this a non-issue. I use both Python and YAML fairly regularly, both have significant whitespace, and I don't have any issues with either.
Also, because YAML doesn't involve things like curly braces all over the place, it's actually notably less friction to type rapidly by hand than something like JSON. I don't think YAML is amazing or anything like that but I do find myself nowadays preferring it, for config at any rate, over JSON.
JSON definitely wins for machine readable data sent over a pipe though because the lack of significant whitespace means it'll compress better.
I would wager that just in the time it takes me to write this comment, millions of yaml documents have been successfully parsed.
Works for me. Until it doesn't. Just like anything else. No silver bullets.
It’s because ppl are not using it correctly, it was designed for configs and now it’s being used as a programming language… a language without types and debugger. It’s frustrating devs because they find the issue at the deployment time, not the compile time.
Personally I did never pick the YAML as a first format for the configs, only my ruby friends did that.
Fair point, that’s why I said I won’t pick it. But it still might be a good and simple choice for small configs, hand written. It does explode when it’s machine generated or templated.
I think it’s also strictly connected with the ecosystem devs are working with, ruby or python devs usually pick YAML, JavaScript/Node devs with JSON - this is how it works, ppl chose what they know and what they are used to.
Next time the author would like to write an article like that, it’s better that they offer a new standard that is as flexible while also doing the work YAML is doing today
That’s the problem people IMO don’t understand - flexibility is one of many requirements; simplicity and ecosystem around are two more.
Hating YAML is same as being childish - yo using like something but can’t come up with anything better. Worse than YAML can be only complaining about YAML. Hating YAML is a cliche.
Its much easier to come up with jokes like this website than to change the ecosystem for better.
And I definitely think the websites like this is opposite to the engineering approach.
> That’s the problem people IMO don’t understand - flexibility is one of many requirements; simplicity and ecosystem around are two more.
Biggest issue IMO is moving goal posts and people wanting one format to do it all. Different formats are good for different things, except YAML, which again tries to do it all yet excels at nothing.
Am I the only one who finds this writing style hard to read?
I stumbled upon this page a few years back and was very confused by the language. It took me some time to parse it and realize that all the comments are actually sarcastic. Overall, the general style feels like I'm reading comments on TikTok.
It's not that I'm against this style; it's just that you don't expect it in a technical article.
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.
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#issuec...
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/), it looks like a more sane way forward.
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.
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.
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.
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.
Yes, true, there is this legendary subset... but parsing even a sane subset of the spec is a nightmare for all parties involved.
> 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.goog...
* 2012: https://news.ycombinator.com/item?id=3912149
I'd say that only really strengthens OP's overall point of being about using "the wrong language for the wrong thing".
Yes: JSON was meant to be a machine-to-machine format, and it's the humans that are insisting on comments.
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.
What do you mean that JSON is not "streamable"?
There are things like https://www.baeldung.com/jackson-streaming-api but maybe there's more in you definition of "streamable" that JSON doesn't satisfy.
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.
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
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.
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?
> 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
See also the comment below: 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.
He misspelled subset/superset, but the idea with streaming is right.
Given: - YAML support streaming - any JSON is valid YAML
Conclusion - any JSON is streaming
Nope?
The "streamed JSON" needs --- line sparators, which is not a JSON spec feature, thus that data stream is valid YAML from that point, bot not a valid JSON stream.
NDJSON is a different beast.
I think you should check this page before making snarky comments: https://en.wikipedia.org/wiki/Inference
See Examples section.
Yaml streams are just yaml docs separated by "---" withing a single file.
The json spec just doesnt do anything like that but jsonl does.
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.
What is Norway? Couldn’t find a reference to it.
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.
> 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!"
I, for one, hate JSON.
chuckle
Well most of that is due to 1.1 which has been deprecated god knows for how long.
1.2 does not have the 'Norway' problem any more.
Tooting my own horn, this is how a modern YAML library looks like nowadays:
https://github.com/pantoniou/libfyaml
I read that as libfuckyaml
Maybe you should get your mind out of the gutter then.
Between us two I am not the one using personal attacks. I advise you to reflect upon your own words.
between us three, I am considering your comments as political propaganda against Norway. And this is off topic here.
So, I advise you, guys, to reflect upon your words.
I don't care what you consider my words.
Surprised TOML didn't get mentioned in the alternatives section, it's probably my favourite configuration format.
I'm working on a project now that uses YAML for configuration (it makes more sense in this context than TOML) and am parsing it using Rust's `serde` crate (via `serde_norway`). It's not so bad if you use `#[serde(deny_unknown_fields)]` everywhere.
I'm still sad that JSON5 never became industry standard.
Unlike hjson, toml and many others, JSON5 didn't try to reinvent the wheel and create a totally new syntax.
Instead, they took 2 already well established standards (JSON and ECMAScript 5.1) and put them together.
I think that it is pleasant enough to write by hand while not creating yet another new syntax that you have to get used to.
[0] https://json5.org/
My usage of YAML has been limited. For the times I have used it (kubenetes, docker compose, other things, etc) -- I don't get what it so special about it.
It just seems reinventing the wheel again and again.
I am not suggesting JSON is perfect, either. However I do prefer it to YAML (and XML) by a mile.
It's a shame s-expressions never taken off.
Or I know - its a sample, but you get it. :-)- "something broke" is way better than stack traces with line numbers
That sums it up. Its the same since the days of XML. Someone decides to make something configurable externally and then everything gets put in there for convenience. Now we are programming in XML/YAML without even a stack trace (or a debugger, or call hierarchy, or type checking or ... )
Pretty sure strictyaml tells you which line was faulty.
Put quotes around your strings an you'll be mostly fine.
It really is that simple.
You really should not blame it on YAML that if you put a random hash value in a field that it may be a number. Like, duh. If you want a string, use quotes.
And use Alpha-3 country codes which are superior in any possible way regardless of YAML :)
What's the problem with alpha-2 codes?
> you'll be mostly fine.
You mean other than when we won't be? :-(
Ctrl+F "KYAML", 0 results
I think KYAML[1] is very relevant here. KYAML is a strict subset of yaml[2], supported natively by kubernetes tooling in most recent versions.
In my opinion it's closer to JSON with comments than to YAML, but overall it looks like a pretty nice format, that solves some of pain points of both technologies. This is not the first nor the only JSON-with-comments format, so I wonder if it manages to break out of kubernetes world and become popular.
[1] https://kubernetes.io/blog/2026/08/11/how-to-pretty-print-ku...
[2] https://www.kubernetes.dev/resources/keps/5295/
I think a format that relies so heavily on invisible characters is terrible, but thats just me.
I used to think the same but I've mellowed.
Modern editors make this a non-issue. I use both Python and YAML fairly regularly, both have significant whitespace, and I don't have any issues with either.
Also, because YAML doesn't involve things like curly braces all over the place, it's actually notably less friction to type rapidly by hand than something like JSON. I don't think YAML is amazing or anything like that but I do find myself nowadays preferring it, for config at any rate, over JSON.
JSON definitely wins for machine readable data sent over a pipe though because the lack of significant whitespace means it'll compress better.
Maybe just my brain but I find it easier to follow those { and [ then tabs and -
Every good editor can make these “invisible” characters visible.
I would wager that just in the time it takes me to write this comment, millions of yaml documents have been successfully parsed. Works for me. Until it doesn't. Just like anything else. No silver bullets.
I actually like the SQL example.
right? Sensible nesting (that's how I'd break and indent a long query anyway), folding in proper code editors, proper hierarchy... what's not to like?
That `AND:` being prefix-order was the hint it just needs a few small finishing touches:
It’s because ppl are not using it correctly, it was designed for configs and now it’s being used as a programming language… a language without types and debugger. It’s frustrating devs because they find the issue at the deployment time, not the compile time.
Personally I did never pick the YAML as a first format for the configs, only my ruby friends did that.
It's also terrible for configs, for many of the reasons specified in the article.
Fair point, that’s why I said I won’t pick it. But it still might be a good and simple choice for small configs, hand written. It does explode when it’s machine generated or templated.
I think it’s also strictly connected with the ecosystem devs are working with, ruby or python devs usually pick YAML, JavaScript/Node devs with JSON - this is how it works, ppl chose what they know and what they are used to.
there's already a better alternative, it's called starlark.
Next time the author would like to write an article like that, it’s better that they offer a new standard that is as flexible while also doing the work YAML is doing today
TOML? It's what I've been using for complex configuration in personal projects (more complex than command line switches)
EDN? Probably too flexible from some perspectives. No surprise Norways though.
That’s the problem people IMO don’t understand - flexibility is one of many requirements; simplicity and ecosystem around are two more.
Hating YAML is same as being childish - yo using like something but can’t come up with anything better. Worse than YAML can be only complaining about YAML. Hating YAML is a cliche.
Its much easier to come up with jokes like this website than to change the ecosystem for better.
And I definitely think the websites like this is opposite to the engineering approach.
Not defending YAML though in particular.
Edit: grammar
> Worse than YAML can be only complaining about YAML. Hating YAML is a cliche.
Its cliche for you, but not all people know about YAML problems.
If it is not interesting for you and people who already know about this, why open this thread?
Let people explore something new, if they are interested in it.
> Its much easier to come up with jokes like this website than to change the ecosystem for better.
Speaking about problems is also valuable. The more people know about them, the more chance of a solution.
> That’s the problem people IMO don’t understand - flexibility is one of many requirements; simplicity and ecosystem around are two more.
Biggest issue IMO is moving goal posts and people wanting one format to do it all. Different formats are good for different things, except YAML, which again tries to do it all yet excels at nothing.
The modern societies are being infantilized. This is a symptom of that.
KDL? https://kdl.dev/
Thanks for the page, I'll feed it to the LLM when it writes yaml next time, probably today.
I won't even look at it, and it will be just fine.
This is hilarious, and so true!
> noyaml.com
Is this supposed to read as Norway's YAML?
I’m sorry but the “If SQL were built on YAML” part is actually better than SQL.
Am I the only one who finds this writing style hard to read?
I stumbled upon this page a few years back and was very confused by the language. It took me some time to parse it and realize that all the comments are actually sarcastic. Overall, the general style feels like I'm reading comments on TikTok.
It's not that I'm against this style; it's just that you don't expect it in a technical article.
Wait until you find shell code inside a pipeline YAML definition. Now that's programming with YAML.
Yelling At My Laptop
YAML is fine. TOML is a lot worse.
Nobody anywhere needed more INI files.
> YAML is fine. TOML is a lot worse.
Care to elaborate? We are using TOML for config files and just do fine.