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 think the claim was that the commercial device never existed but that it was too obscure for the friend to randomly independently get targeted ads about it..
But I don't think WhatsApp takes many steps to protect media and in many cases the user really wants to backup media or share in other apps, etc, over security for media.
I can't believe I'd ever find myself shilling for Google of all companies, but how is it sustainable from a creator's point of view if the viewer neither pays for a subscription nor looks at the ads?
YouTube was better before it was taken over by career content creators. People used to make videos because they wanted to share something with the world. It was more authentic. Now everything is about clickbait and maximizing revenue.
Don't get me wrong, I'm happy that they can get some money from it, but maybe there's too much money now. Every time I hear about a YouTube creator quitting their job and going pro, I fear for the future quality of their output.
Google is doing this for their advertisers, not creators. They have already pulled the rug out for under them with AI search queries and timestamp links that circumventthe creator's own in-video ads.
I don’t ever pay for a subscription or look at ads on YouTube. I support the creators I like by donating, patreon, buying merch, etc, all of which avoid a monopolist taking an outsized cut of their earnings.
Thank you! It came out of that feeling of I need to use this, but I don't want to have to manage it or have to learn the details more than once. Now I find myself using it daily in my workflow, not having to worry about the extra worktree folders saves enough time to make it worthwhile
> This network effect is particularly strong with messengers like Apple Messages (formerly known as iMessage) and, especially in the global south, as well as underdeveloped regions, WhatsApp.
WhatsApp is extremely popular in many European countries, too.
reply