I believe YAML has serious issues and I would not be using it as a configuration format. But I think a lot of the criticism around YAML misses the mark. YAML i

I believe YAML has serious issues and I would not be using it as a configuration format. But I think a lot of the criticism around YAML misses the mark. YAML is not excessively overused as configuration language. It is not dominant like XML was back in its heyday. TOML has a pretty strong mindshare, and many projects are still using JSON or XML. I would pick TOML over YAML any day for this usage, but I still think YAML beats XML and JSON (just think about comments and terrible merge resolution whenever you add an item to an array or an object). But YAML does reign supreme in the world of DevOps-oriented DSLs. YAML is more suited for DSL compared to alternatives, like TOML, JSON, JSON5 or XML: - YAML is the least verbose of all alternatives (especially XML, but even JSON5 and TOML). - YAML requires the least of amount of "syntax noise" on top of your DSL. The "syntax noise" is mostly limited to indentation, colons, dashes (for arrays), indented text block markers and occasionally quotation marks. JSON, JSON5 and TOML require quoting all string values and explicitly marking arrays and object boundaries, which make the DSL seem less fluent. XML is even worse. - YAML supports indenting multi-line strings, so you can easily embed other formats. This makes adding markdown descriptions (in Swagger/OpenAPI) or embedded shell scripts (in YAML-based CI/CD DSLs) a breeze. - YAML syntax is hierarchical. The same is true for JSON and XML, but not for TOML. TOML syntax only has two fixed and assymetrical tiers of hierarchy: sections and key-value pairs. Hierarchy can be achieved while parsing, by grouping sections hierarchically, but this is not reflected in the syntax, and this property makes TOML ill-suited for DSLs. Of course, TOML was never meant to be used for DSLs - it's was designed as a configuration language, just as JSON was designed to be a simple data exchange format and XML was designed as a document markup language. But if you had to choose any of the format above to base your DSL on, YAML seems like the natural choice. What is the best alternative to YAML then? Probably writing your own parser and removing all unnecessary cruft that you keep to make your DSL fit the YAML straitjacket. And that's the real problem, and the real reason why YAML is overused: parsing YAML is easy, but writing your own custom parser is hard. Sure, most languages have at least one easy to use library that lets you implement a basic parser based on PEG or parser combinatorics quite easily. But even then you have to deal with all the fun things like: ambiguities (or lack thereof[1]), the limitations of whatever parsing technique you've chosen, tokenizing newlines and indents and parsing a token tree that is still not as clean and easy to parse as YAML. YAML is still two or three order of magnitudes easier than even writing the simplest parser, so most tool writers pick up it for writing their DSL. This is the age-old "worse is better" principle. It is faster and easier to release and iterate on YAML-based tooling, so most projects pick up YAML and the ones that pick up YAML tend to both ship and iterate faster, and then go ahead to capture the market. > IMO if there was something that was substantially better, we would see projects switching to it in a heartbeat. Maybe not in a heartbeat, but I do think most of the "YAML alternatives" out there didn't even try to address DSLs. Maybe we should admit defeat on the make-your-own-parser front and design proper DSL carrier language that can be at least somewhat better than YAML. [1] https://jeffreykegler.github.io/Ocean-of-Awareness-blog/individual/2015/03/peg.html https://jeffreykegler.github.io/Ocean-of-Awareness-blog/indi...