It's due to fragmentation in implementations. The YAML spec is fairly large, and library authors understandably aren't excited at the prospect of dealing with all the minor details of less commonly used bits, like anchors.
You end up with YAML libraries being widely available and they all implement _most_ of the spec, but the portion not implemented varies. Plus there are minor variations in how people have read the spec, and even options _within_ the specification on how to handle parsing:
This isn't really a problem for projects like Kubernetes where most of the ecosystem uses the same library. On the other hand, OpenTelemetry is rolling out "declarative configuration" across all the supported languages. I work on OTel, and have avoided contributing in that area because I lack the patience to deal with the inconsistences - I don't hate YAML, but it can be frustrating.
AFAIK, the only 100% spec compliant implementation is libfyaml.
I see. I still wonder if the criticism is warranted in the particular context of Ansible playbooks.
First of all, who except Ansible (and ansible-lint) would even want to consume Ansible's YAML?
Regarding anchors: those are not idiomatic in Ansible at all, thanks to Ansible offering first-class support for object reuse on application level (e.g. variables and facts).
I wonder if TFA's pounding on YAML might be undeserved in this particular context.
I don't think YAML syntax is the core problem but understanding them as text files and not as serialized dicts/maps and lists.
Hell starts to open when people use string template languages to generate YAML files, such as in Helm charts. This is stupid because the templating language is not aware of the host language semantics. It is quite similar to the SQL or HTML injection problem we fought 20yrs ago and finally overcame with templated queries and auto-escaping.
I don't get the YAML hate.
It's due to fragmentation in implementations. The YAML spec is fairly large, and library authors understandably aren't excited at the prospect of dealing with all the minor details of less commonly used bits, like anchors.
You end up with YAML libraries being widely available and they all implement _most_ of the spec, but the portion not implemented varies. Plus there are minor variations in how people have read the spec, and even options _within_ the specification on how to handle parsing:
https://yaml.org/spec/1.2.2/#chapter-10-recommended-schemas
This isn't really a problem for projects like Kubernetes where most of the ecosystem uses the same library. On the other hand, OpenTelemetry is rolling out "declarative configuration" across all the supported languages. I work on OTel, and have avoided contributing in that area because I lack the patience to deal with the inconsistences - I don't hate YAML, but it can be frustrating.
AFAIK, the only 100% spec compliant implementation is libfyaml.
I see. I still wonder if the criticism is warranted in the particular context of Ansible playbooks.
First of all, who except Ansible (and ansible-lint) would even want to consume Ansible's YAML?
Regarding anchors: those are not idiomatic in Ansible at all, thanks to Ansible offering first-class support for object reuse on application level (e.g. variables and facts).
I wonder if TFA's pounding on YAML might be undeserved in this particular context.
I don't think YAML syntax is the core problem but understanding them as text files and not as serialized dicts/maps and lists.
Hell starts to open when people use string template languages to generate YAML files, such as in Helm charts. This is stupid because the templating language is not aware of the host language semantics. It is quite similar to the SQL or HTML injection problem we fought 20yrs ago and finally overcame with templated queries and auto-escaping.