@ainmosni@social.ainmosni.eu Most of the pain in YAML comes from the automatic type casting in implementations. I loved YAML until I worked with it in any language other than Perl. Perl famously doesn't have "types", the context determines the type. It's controversial, but it made working with YAML, well, simple and predictable.
YAML is attempting to serialize and abstract (ie, make computer things more human friendly). If you remove the implicit type casting from the deserialization process, I think things get much easier to deal with. Aside from numbers and strings, I don't think YAML or the YAML libraries should deserialize into native types. If you want to use the value as a datetime field, do the type cast explicitly in code. The Norway problem disappears. If you want a boolean, you cast yourself, explicitly. The bad data problem becomes the application's domain to handle. If you expect a Datetime in a certain field, the programmer is responsible for the type casting and error handling, not the library.
I think the serialization aspect of YAML was naive. At this point in history, looking at how YAML is used, it's clear that serialization was a mistake and the minority use case. Most YAML is config. Config doesn't need type casting, it needs application specific validation. The serialization might save some devs a few keystrokes, but at what cost?
I say this as someone who loved YAML when working with it in Perl. I started working with pYAML in Ansible and it broke me. pYAML is fucking terrible. It's slow, incorrect, and volatile. And in the context of the Ansible, the types are fucking worthless anyways.. Inevitably, the YAML serialized number gets converted to a string somewhere between the deserialization and the jinja2 because you have to use quotes to use inline jinja2, so all my fucking templates have to |int or |float anyways. It's mind numbingly stupid.
Apologies if that's too much. I think I may need to talk to a therapist about my YAML trauma.