[TheDong]

> Easy to write and read by hand, while also being easy to write and read with code in just about every language

Language implementations for yaml vary _wildly_.

What does the following parse as:

    some_map:
      key: value
      no: cap

If I google "yaml online" and paste it in, one gives me:

{'some_map': {False: 'cap', 'key': 'value'}}

The other gives me:

{'some_map': {'false': 'cap', 'key': 'value'}}

... and neither gives what a human probably intended, huh?

[karmarepellent]

This is why I've become a fan of StrictYAML [0]. Of course it is not supported by many projects, but at least you are given the option to dispense with all the unnecessary features and their associated pitfalls in the context of your own projects.

Most notably it only offers three base types (scalar string, array, object) and moves the work of parsing values to stronger types (such as int8 or boolean) to your codebase where you tend to wrap values parsed from YAML into other types anyway.

Less surprises and headaches, but very niche, unfortunately.

[0] https://hitchdev.com/strictyaml/

[sauercrowd]

That only matters if you're parsing the same yaml file with different parsers, which GitHub doesn't (and I doubt most people do - it's mostly used for config files)

[sevensor]

“The meaning of YAML is implementation-defined” is a big reason I stay far away whenever I can.

[Perz1val]

The classic Norway bug