(select (num name)
     :from  customers
     :where (exists (select name
                       :from  orders
                       :where (and (= customers.num
                                      orders.customer_num)
                                   (< price 50)))))

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

Google put forward KYAML recently (https://www.kubernetes.dev/resources/keps/5295/), it looks like a more sane way forward.

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!"

So surely if YAML is streamable, JSON must be too?

Or are the YAML maintainers incorrect?

The json spec just doesnt do anything like that but jsonl does.

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.

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.

Given: - YAML support streaming - any JSON is valid YAML

Conclusion - any JSON is streaming

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.

See Examples section.

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.

And then you have whatever the hell OpenAPI uses.

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

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.

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

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.

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.

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.

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.

You mean other than when we won't be? :-(

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

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.

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

So, I advise you, guys, to reflect upon your words.

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.

Nobody anywhere needed more INI files.

Care to elaborate? We are using TOML for config files and just do fine.

Personally I did never pick the YAML as a first format for the configs, only my ruby friends did that.

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.

I won't even look at it, and it will be just fine.

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/

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/

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")))

  (orders
    (order
      (id 1)
      (code "aa1")
      (qty 32)))

Is this supposed to read as Norway's YAML?