I’ve found that a big “saving grace” for YAML is that anything that is valid JSON is also valid YAML. My go-to fix for having to work with large amounts of YAML has been to generate JSON via jsonnet and use that instead.
Heredoc support
Multi-line string support
RFC3339 date support
Better Unicode support
Proper support for 754 floating point special values ( +/- inf, nan, etc.)
This. I’ve been using TOML for some things lately and other than array of tables and table of tables it just sort of works.
I believe the problem with YAML is that it tries to be both a human-facing configuration language a machine-friendly interchange language. I really like UCL for separating the two concerns. UCL provides a set of rich features for things like includes with priority-based merging and unit suffixes but can also take a config directory and merge the result into a single JSON document (or some other serialisation). Your front end can take complex UCL structures but then send the back end a single blob that’s easier to parse.
Ah, but there is no way in JSON to indicate that a string contains Base64-encoded binary data, rather than is a string which happens to decode to Base64 without errors. As an example, is the string “your” Base64-encoded binary data, or an English word?
I don’t think it’s a typing issue, so much as it’s a value issue: what is the value of the string "foot"? Is it the bytes 146, 157, 157, 164 or is it the bytes 126, 138, 45?
Although, if types don’t matter, one might argue against distinguishing "2.0" and 2.0. Heck, we could just adopt Tcl literals, where everything is a string. Instead of {"foo":2, "bar": "baz"} we could just have foo 2 bar baz. That wouldn’t bother me too much, to be honest, but I think most folks wouldn’t care for it!
The absolute worst offender is helm templated yaml, it’s very easy to screw up the level of nesting. At best you get an invalid yaml file and it fails to apply. At worst you get a valid yaml file that’s doesn’t do what you want it to do and you don’t realize until later.
Just use XML. Especially because versioning is really easy and just works.
E. g. You have a new config version 2, so your define your new schema, and the XSLT to convert your config version 1 to config version 2, and never have to think about it again (or deal with multiple config versions in your application).
JSON is terribly unreadable with large configurations and YAML has it’s quirks. People rag on XML because its the cool thing to do, but it gets the job done.
Unpopular opinion: I abolutely love YAML as a human readable data format. It has all the right features. Unfortunately it is abused with layers of templating, and is used for “programming in YAML”.
Nice features:
“here document”/multiline string support. Sometimes very handly. I don’t know of other serialization format that knows it.
id support, to be able to represent cycles in object graphs natively
no need for explicit closing of structures, good streamability. (I have seen xml/json logging, either with extreme overhead, or with malformed, contents)
pretty human readable, better than JSON.
comments
the indentation based syntax is not that bad (though I’m also OK with it in Python and F#)
YAML is nice for configs, and many simple serialization tasks (though not efficient at that). Just don’t use it as a programming language.
I’ve found that a big “saving grace” for YAML is that anything that is valid JSON is also valid YAML. My go-to fix for having to work with large amounts of YAML has been to generate JSON via jsonnet and use that instead.
After getting into some really annoying OpenAPI YAML files, and then fighting with it in docker ecosystem and elsewhere, I’m pretty over it.
For all the pissing and moaning, I am perfectly content to use JSON for everything. The only features it is actually missing in my opinion are:
That’s it. That’s all I want. Everybody wants to add other shit–knock it off.
This. I’ve been using TOML for some things lately and other than array of tables and table of tables it just sort of works.
I believe the problem with YAML is that it tries to be both a human-facing configuration language a machine-friendly interchange language. I really like UCL for separating the two concerns. UCL provides a set of rich features for things like includes with priority-based merging and unit suffixes but can also take a config directory and merge the result into a single JSON document (or some other serialisation). Your front end can take complex UCL structures but then send the back end a single blob that’s easier to parse.
JSON is also missing binary-data support, and needs it badly.
You can base-64 encode binary data and store it as a string, so it doesn’t make my list.
Ah, but there is no way in JSON to indicate that a string contains Base64-encoded binary data, rather than is a string which happens to decode to Base64 without errors. As an example, is the string “your” Base64-encoded binary data, or an English word?
There’s also no way to tell if a field
1.0is dealing with pounds or kilograms, right?That’s a type problem, which JSON mostly doesn’t (and in my opinion, shouldn’t) provide.
I don’t think it’s a typing issue, so much as it’s a value issue: what is the value of the string
"foot"? Is it the bytes 146, 157, 157, 164 or is it the bytes 126, 138, 45?Although, if types don’t matter, one might argue against distinguishing
"2.0"and2.0. Heck, we could just adopt Tcl literals, where everything is a string. Instead of{"foo":2, "bar": "baz"}we could just havefoo 2 bar baz. That wouldn’t bother me too much, to be honest, but I think most folks wouldn’t care for it!The absolute worst offender is helm templated yaml, it’s very easy to screw up the level of nesting. At best you get an invalid yaml file and it fails to apply. At worst you get a valid yaml file that’s doesn’t do what you want it to do and you don’t realize until later.
Just use XML. Especially because versioning is really easy and just works.
E. g. You have a new config version 2, so your define your new schema, and the XSLT to convert your config version 1 to config version 2, and never have to think about it again (or deal with multiple config versions in your application).
JSON is terribly unreadable with large configurations and YAML has it’s quirks. People rag on XML because its the cool thing to do, but it gets the job done.
Unpopular opinion: I abolutely love YAML as a human readable data format. It has all the right features. Unfortunately it is abused with layers of templating, and is used for “programming in YAML”.
Nice features:
YAML is nice for configs, and many simple serialization tasks (though not efficient at that). Just don’t use it as a programming language.
Also: RFC format is not that nice imho.