Hacker News Reader

Comment by yashap | Hacker News Reader

I’m a fan of JSON5. A common criticism is “we’ve already got YAML for human readable config with comments,” but IMO YAML’s readability sucks, it’s too hard to tell what’s an object and what’s an array at a glance (at least, with the way it’s often written).

When dealing with large YAML files, I find myself frequently popping them into online “YAML to JSON” tools to actually figure out WTF is going on. JSON5 is much easier to read, at least for me.

View on HN

Those two criticisms of YAML are at bottom of my list. Space as delimiter and lack of strict typing is what screws me over on daily basis as SRE.

This. I hate how all these serialization/config formats come out of dynamically typed languages. Static typing is a must. Then so many classes of errors go away.

Just static type then. You can’t trust incoming data shapes anyway, e.g. if it specifies a schema and doesn’t even follow it. You always expect something in a typed language, not anything. So validate it and that’s it. Thinking that dynamic data can be typed is a mistake. It can only be structured ([], {}, "", …) into basic types and then matched to some template. Any above-data section about types is as good as none. It can help a human to make sense of its shape, but that’s it.

You might like Dhall

Fair, YAML has a lot of usability warts, and those suck too. Although personally I really do hate how tough it is to tell apart arrays and objects, at least with the most common YAML array/object style.

Just in case you didn't know: With https://github.com/mikefarah/yq you can just immediately translate YAMLs like

  yq some.yaml -o json

A reimplementation of jq in golang supports reading yaml and, of course, emits json: https://github.com/itchyny/gojq#:~:text=supports%20reading%2...

That one is likely more relevant than yq since folks in the json ecosystem are far more likely to be familiar with jq's syntax and thus using gojq is "one stop shopping," not to mention that its error handling is light-years beyond jqlang's copy

Yes, but I LOVE yq's ability to update YAML files without stripping existing comments. For example, I use it to programmatically update similar (but not identical) GitHub Actions files across projects.

> When dealing with large YAML files, I find myself frequently popping them into online “YAML to JSON” tools to actually figure out WTF is going on.

YAML is a strict superset of JSON, so defining the former in the syntax of the latter is fully supported by the spec. Perhaps not by every YAML library, to be sure, but those which do not are not conformant. From the YAML spec[0]:

  The YAML 1.23 specification was published in 2009. Its 
  primary focus was making YAML a strict superset of JSON.

0 - https://yaml.org/spec/1.2.2/

I'm confused about your point about YAML being "strict superset of JSON" leading to being able to convert YAML to JSON.

If YAML is a strict superset, wouldn't that mean that YAML must have at least one feature that is not part of JSON? Wouldn't that make it impossible to define all YAML files as valid JSON?

They all turn into the same data types in the end. You can import a YAML and output a JSON.

For a feature like references, you'd have to do the annoying thing and duplicate that section of the file.

For a feature like unquoted strings or extra commas, you just quote the strings or remove the commas.

The various YAML features are in between and mostly close to the latter.

> If YAML is a strict superset, wouldn't that mean that YAML must have at least one feature that is not part of JSON?

Yes. One of the features YAML supports is the widely documented format we are all familiar with.

However, being a "strict superset of JSON" also means a conformant YAML implementation can load a "pure" JSON resource without issue. The converse is not generally possible as JSON cannot express what YAML can, such as octothorpe ('#') comments.

HTH

For sure, but most YAML you actually encounter does not use much in the way of JSON syntax, it looks a lot more like this: https://devblogs.microsoft.com/devops/wp-content/uploads/sit...

Where arrays and objects just look too similar (IMO), white space is significant, most strings are unquoted, etc. And personally I find it quite difficult to really understand what’s going on there, at a glance, compared to JSON (or JSON5).

> For sure, but most YAML you actually encounter does not use JSON syntax

So what? YAML can be trivially mechanically translated between flow and block syntax.

I want to be able to easily read and understand configuration without having to pop it into a converter. The YAML I encounter in the wild is ~80% pure block style, ~20% mixed (within a single file, mostly block style with some flow style). And I just find the block style hard to read, I have to either spend significant mental effort trying to understand where the objects vs. arrays are, or I have to pop it into a converter (to either JSON or flow style) to understand. Whereas JSON/JSON5, it’s immediately clear without any mental overhead.

What's your take on prototxt files? In my opinion it is the most readable format since you don't need square brackets for repeated fields/arrays.

Additionally plugins let you link your prototxt file with the corresponding proto so you can spot errors right away.

Don’t have any experience with them.

If you already have a bunch of JSON documents, you can keep using them with JSON5.

That's a big advantage compared to converting to YAML.

same is true of YAML as a JSON superset

Reply on news.ycombinator.com