There are a lot of valid complaints about YAML, but I still reach for it when I really only need a barebones configuration file.
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.
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!
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.
Requires some amount of legibility out of the box due to whitespace requirements.
Can store complex data structures (and even direct JSON).
Allows comments.
which makes it terrible due to semantic whitespace rules.
parsers shouldn't care about legible whitespace
linters should care about legible whitespace
It comes bundled with something. Question answered.
TOML may get more popular due to Rust.
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.
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.
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.
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.
> Starlark is intended not for writing applications but for expressing configuration: its programs are short-lived and have no external side effects
I also don't think it has threading primitives
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.
I think the YAML as code comes from using YAML as a DSL and writing an interpreter.
I think the reason people don’t is that JSON is terrible for writing my hand and YAML isn’t.
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.