For all of its warts, YAML hits the sweet spot between readability, writability, commentability, and (mostly) intuitive syntax. It's easy to serialize complex objects to, and comes bundled with Ruby's runtime.
There are a lot of valid complaints about YAML, but I still reach for it when I really only need a barebones configuration file.
> For all of its warts, YAML hits the sweet spot between readability, writability, commentability, and (mostly) intuitive syntax.
Could not disagree more strongly and it seems many others in software agree, based on this comment section and the original article.
> It's easy to serialize complex objects to, and comes bundled with Ruby's runtime.
I don't know that Ruby support is why it's widely adopted. Ruby is common in some spaces, but not a wildly popular language at all.
I honestly think some popular project (maybe Docker Compose or something from HashiCorp?) used it for a config file and then everyone else started doing it too.
> Could not disagree more strongly and it seems many others in software agree, based on this comment section and the original article.
They sure do! But lots of people also agree, as evidenced by people continuing to use it. The world keeps turning, and we engineers keep using suboptimal things.
> I don't know that Ruby support is why it's widely adopted. Ruby is common in some spaces, but not a wildly popular language at all.
Ruby’s now gone out of fashion, but it was the most popular web development language (especially among startups) for the better part of a decade. It’s conjecture, but I wouldn’t be remotely surprised if Ruby brought YAML into a lot of shops by virtue of bundling it. Docker (and Docker Compose) came into full force a few years into Ruby’s peak, so it’s the egg to Ruby’s chicken. And we’ve all forgotten that Hashicorp was originally a Ruby shop!
> I honestly think some popular project (maybe Docker Compose or something from HashiCorp?) used it for a config file and then everyone else started doing it too.
Kubernetes maybe? It also supports JSON but JSON is less friendly to manual editing and source control IMO.
Anyway, sure, a lot of people in software disagree. For almost any opinion you might have, you could find many to agree, and many to disagree.
Travis CI predates Gitlab CI by several years, and uses YAML. Definitely a big source of peoples’ YAML experiences these days, but not one of the original ones.
If you've ever tried managing complex, human-centric configuration in JSON, XML, ini, or most any other format, you realize it ticks a lot of the checkboxes that are necessary for a good human-readable configuration format:
Requires some amount of legibility out of the box due to whitespace requirements.
Can store complex data structures (and even direct JSON).
I like TOML a lot, but it still misses a few of the checkboxes: it’s not actually bundled with Rust, and the table syntax is pretty unintuitive (IMO) compared to YAML’s array-of-dictionary syntax.
It has no big boobytrap for beginners, on simple enough patterns it looks very clean and simple, it allows comments while being easy to convert to JSON.
I think these are the main things that push yaml. In particular, being clean and simple for straightforward data is a big plus: configurations are often just key-value lists of ver small strings, having something that is readable and looks simple helps a lot.
And for anything that needs more finesse, switching to XML or JSON is often supported.
The same reason visual programming languages keep making a comeback: people keep thinking they could make programming easy if they could just get rid of that pesky "code" part.
Really I think what the popularity of YAML is saying is that we need a vastly simpler programming language.
Most programming languages are written to impress other programmers. We need a programming language which is trivial to learn, which you couldn't ever use to write a webserver, but you would use it to configure one.
On the contrary, I think the popularity of YAML says that most people want a horribly complicated language that will guess what they mean and so feel simple to write, rather than a language that's simple to understand. It's the language equivalent of tag soup, or Perl.
Something like Dhall is much better for long-term maintainability. But people don't want a language that makes them write consistent, maintainable code. They'd rather have a language where you can leave the quotes off your strings and it will work most of the time except when it doesn't.
that's what i'm talking about. people don't want to know about first class functions, closures, immutability, monads, object orientation, polymorphism, inheritance, generics, contravariance, covariance, threading, concurrency, race conditions, memory safety or package managers. they just want to whip up some shit and have it work.
and you're right they don't care about long-term maintainability at all. that leads to all the conceptual overhead though. they'd rather have a horribly bolted together language than be forced to worry about the concepts that lead to long-term maintainability.
No, I don't think so. That is still aimed at programmers and looks like it has decent threading support and you could write a webserver in it.
I'm thinking more like an actual shell scripting language where you have control flow, some modularity, good support for dealing with unstructured data and the ability (for software developers) to plug DSLs into the back end of the language and expose them to end users to use, and that's about it. First class functions, closures, immutability, object orientation, etc would not be in the language to keep it conceptually simple. This would render the language pretty useless for building applications out of it, but the point would be to gear it more towards people who didn't know those kinds of compsci concepts at all.
The goal would be the least amount of conceptual overhead possible and therefore the most amount of accessibility.
There are parsers for it in every language, and it's more capable than JSON.
Here's what I want. Something that is more readable than JSON, so either TOML-like or YAML-like, but without executable code or any of that nonsense. On top of that, a schema definition file (think XSD) that asserts facts about the structure of the config, using a theorem prover like Coq or Idris.
This way, we get nice configs, but within a restricted space.
Sure. That’s not a YAML problem as it’s not part of the spec. Someone could to the exact same thing with JSON and use a custom spec that is a string starting with a bang and executes it.
I think the reason people don’t is that JSON is terrible for writing my hand and YAML isn’t.
I think the main idea is to have a config file standard that can be used across different project regardless of the language / tool used?
A benefit is that knowing yaml may at least give you the ability to configure the system, even if a project is built using an unfamiliar programming language.
Sometimes people that can read code, like most of us here, don't get bothered by tokens like "{" or some of the more complex hierarchical structures but for someone that doesn't want to learn/understand code YAML is much more appetizing.
