57 ms·
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 t
by yashap 2y ago
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.
- BurningFrog 2y agoIf 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.
- knowsuchagency 2y agosame is true of YAML as a JSON superset
- stackskipton 2y agoThose 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.
- yashap 2y agoFair, 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.
- Pxtl 2y agoThis. 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.
- lmm 2y agoYou might like Dhall
- wruza 2y agoJust 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.
- marcyb5st 2y agoWhat'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.
- yashap 2y agoDon’t have any experience with them.
- couscouspie 2y agoJust in case you didn't know: With https://github.com/mikefarah/yq https://github.com/mikefarah/yq you can just immediately translate YAMLs like yq some.yaml -o json
- mdaniel 2y agoA reimplementation of jq in golang supports reading yaml and, of course, emits json: https://github.com/itchyny/gojq#:~:text=supports%20reading%20from%20YAML 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
- bbkane 2y agoYes, 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.
- AdieuToLogic 2y ago> 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/ https://yaml.org/spec/1.2.2/
- Centigonal 2y agoI'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?
- Dylan16807 2y agoThey 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.
- AdieuToLogic 2y ago> 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 EDIT: see also https://news.ycombinator.com/context?id=42361994 https://news.ycombinator.com/context?id=42361994
- yashap 2y ago