Hacker News Reader

Comment by pavel_lishin | Hacker News Reader

> Regardless of whether YAML 1.2 has been (or will be) widely adopted, it does not help those who want to parse a JSON document with a YAML parser.

Who are these hypothetical lunatics?

View on HN

It works in most trivial cases, so I'm assuming it's widely done irl.

Imagine building some small app that reads external config file. You personally only care about yaml files, but your avid users ask for official json support as well because of a few of their files.

It's not high priority, but as you remember the old saying, json is just a subset, so you try a bunch of files, confirm it works well enough, and decide to pipe JSON files to your yaml parser as well. Done and done.

And it's not so big block of code or anything that jumps at the users, the dev just happens to share a parser between formats.

Configuration systems like Kubernetes and Docker Compose use YAML parsers that accept JSON as input, allowing users to write in either format without changing the tooling.

but the things is there is a difference between

1) a parser which can handle both (based on detecting both and then switches the parsing depending on it)

2) a parser which is made for YAML and happens to be able to parse JSON

I don’t like writing YAML. I like writing Python. So I write Python that generates YAML config files. JSON is in the standard library but YAML isn’t. So I generate JSON and name the file “file.yaml”.

GitHub Actions, Dependabot, and Docker Compose never complain.

Anyone who wants to convert a piece at a time to yaml, but would prefer to just use a single parse step (as suggested by one of the quoted bits in the article). It's a niche case, but sensical.

For real. You can find hardened, optimized JSON parsers for every runtime worth running. Hard to think of why you would want to avoid all those JSON parsers and use a YAML one to parse JSON.

> those who want to parse a JSON document with a YAML parser.

I've done it. We already had a YAML parser in an internal library I maintain since we were already ingesting YAML files for other reasons, so when we later added new files for a different reason that someone decided should be in JSON instead, it was easier and cleaner to keep using the existing YAML parser we already had incorporated rather than add a separate JSON parser along side it.

Ruby on Rails has a databases.yml that is preprocessed by ERB. I often do something like:

    field: <%= File.read('/foo/bar').to_json %>

Though I have myriad criticisms of YAML, this article's arguments are not a concern at all if you can ensure that your YAML parser always uses 1.2 regardless of any %YAML directive.

As someone who has written a lot of YAML-compatible software, this is my biggest takeaway: every single YAML-parsing tool is incompatible with each other (in some way). If two tools work together, it's an accident. They will work for a while until someone tries to do something with one tool that the other tool doesn't like.

If all you do with YAML is serialize data, from one tool, to the exact same tool, it's fine. For all other purposes you should seek a different data format (if you don't want to deal with the eventual bugs).

(note that I don't mean parser/library, I mean tool. the tool using the library will often use or not-use certain options which increases the complexity of the interactions and leads to more possible failures)

You want to use a machine to create a document for something that accepts JSON. e.g. Something I was playing around with was having a github workflow that generates a github workflow. Or generating docker compose files.

Kubernetes is a good example. Objects can be read / written as json or yaml interchangeably.

It’s not an example at all. It uses different parsers and renderers for each format.

The parent comment asks the question "Who are these hypothetical lunatics?". I don't know what today's Kubernetes parser does but it seems plainly obvious that Kubernetes would be a consumer of "YAML as JSON superset" parser if it exists. It isn't as though users are expressing different things with JSON than they are with YAML.

Ah, there y'all are.

people stuck with sub-par tooling

(weather that's because of laziness, better tooling not being available/integrated, not know, not being usable or them being stuck on a ideological delusion where they insist on not using it doesn't really matter)

like sub-par tooling is one of the 2 main reason of when it comes to problems with config or data serialization format (bugs, strange edge cases, etc.)

the other is people obsessing with handling things the exact same way, which might looking similar from far away but have major different details/constraints/dynamics when you look closely at them. (like config parsing vs. data deserialization vs. ad-hoc languages on top of a config format)

Reply on news.ycombinator.com