One of my favorite bugs of all time, which turns out to be a pretty common yaml bug (the article touches on a similar example), was when we used yaml to configure some localizable data. Everything worked fine until Norway came online. Sweden worked fine, so did Denmark and every other country, but the app crashed when it loaded the config for Norway.<p>Turns out the country code for Norway, "no", is interpreted as boolean false when unquoted in yaml.
I've never understood the love for significant whitespace. I see where the idea came from - "No more missing semicolon errors! Woohoo!" - but it should've been clear after trying out the idea for five minutes that it was not at all worth it. It constantly causes trouble and all just to save a couple of keystrokes.<p>Though: now that I think about it, most of the problems happen at the block level, not the line level. So maybe significant newlines are fine but not indentation.
Nearly every time I have to make any changes to a CI environment (or set one up for a new project), I end up with a stream of increasingly unintelligible and often increasingly grumpy commit notes. It's almost always because YAML, as a format, is confusing and frustrating to write.<p>Structured data with only vague, and often misleading, indication of its structure is awful to work with. Sure, it's "human readable", but if your data is of any real complexity you're almost certainly better off just machine-generating it.
Heartily agree with this post.<p>One of the things I most dislike about yaml is that they persuaded JSON to remove comments from the spec for some psuedo compatability nonsense. Without comments, json is less useful for config files and working/documented examples.<p>I have written a pre-parser to permit comments in JSON and for nodejs apps I use javascript as config. Naturally where security is not a concern.<p>Yaml always seemed like a mess to me.<p>Liking Toml, decent compromise.<p>And linux style: name space value, hash and semi for comments. Unless I really need a heirachy.
I find YAML distressingly hard to work with. Just one example- because it’s white space delimited, copying and pasting a block of code will often blow up between docs based on nesting levels. This is intensely frustrating when the setting is tied to a CI pipeline that takes 5 minutes to get to the error.<p>The human unreadability if JSON is greatly exaggerated. While you can get horrible looking JSON, you can also then pretty print it into something much better. If we could just all agree to allow comments into a spec it’d be fine.
Since he opens by referring to a similar argument against JSON for human-editable configuration files, I wondered what format he did like for that. Answer at the end appears to be TOML, if you must have one at all.<p>> Don’t get me wrong, it’s not like YAML is absolutely terrible – it’s probably better than using JSON – but it’s not exactly great either. There are some drawbacks and surprises that are not at all obvious at first, and there are a number of better alternatives such as TOML and other more specialized formats.<p>> One good alternative might be to just use commandline flags.<p>> If you must use YAML then I recommend you use StrictYAML, which removes some (though not all) of the more hairy parts.<p>(I do agree YAML is in retrospect a mistake. The reasons why remind me in some ways of the problems with Markdown).<p>(Oddly, I can't seem to find an up to date TOML parser in ruby that supports the 1.0 spec...)
Fun fact: YAML is a superset of JSON. That is, any JSON is also valid YAML.<p>YAML is a complex and unintuitive mess that allows doing every thing in a million ways. I’m surprised it ever got so much traction. TOML is a breath of fresh air next to it.
Wait, what? It's built in to the format that it can execute arbitrary shell commands?<p>"Who approved this?!"<p>I can't imagine the cluster fuck of ideas in a person's head to lead to thinking that this was an ok design for a configuration file. The person who designed this and I just don't live on the same planet.<p>And here I thought the reason I didn't use YAML was because the syntax looked stupid.
YAML allows escapes to executable code?<p><pre><code> !!python/object/apply:os.system
args: ['ls /']
</code></pre>
Who put that backdoor in?
When I first saw json, compared to XML, it was so simple. As a fairly new programmer I could say to myself “hey I can write a parser and dumper for this quite easily”.<p>When I first saw YAML, it was nice but it felt a bit too complicated.<p>All I really want is Indented JSON. New lines instead of commas. That’s it.<p>Json is fast to parse. See simdjson doing it at > 2.5GB/s. One can’t do this with YAML where no could mean many things.<p>And god I hate k8s for their bajillion yaml configs. Thank god for jsonnet that can dump to yaml. Jsonnet is truly nice and makes working with json like configs a pleasure.
I see a lot of criticism of YAML, and I’ve looked a few other minimal configuration languages like TOML as well.<p>Serious question: why doesn’t this language space have a universally adopted candidate like SQL?
The specification of YAML is about three times as long as XML 1.0, but while XML includes a whole grammar-based validator with such niceties as referential integrity of IDs and default values for omitted parameters, YAML spends all this on syntactic sugar.
YAML isnt my idea of clarity but thats fine. I tend to go with using a python script to generate a json file. This supports comments, if-else decision making, modules and all sorts of other smarts. Tell users not to edit the resulting json file - its readonly.<p>Python gives you all the power of scripting including validation and json gives you the easily readable format for both humans and machines. Great for knowing exactly what the settings evaluated as.<p>And when you don't need the power of full expressive python script, you can just json.dump() a python dictionary and be done with it.<p>I've also used sqlite as a config file format and that is very polite and easily read from anything I use.
<a href="https://cuelang.org" rel="nofollow">https://cuelang.org</a> is a very nice alternative that has nice import/export support for yaml among others
I have not seen anything that could come close to the robustness and flexibility XML has to offer. When being used for configuration XML seems to be the superior choice. People tend to give XML a bad name in RPC usage for being verbose. But, for config it’s perfect for me.<p>There are tons of IDEs supporting XML (syntax highlight & collapsing brackets, etc...). XML schema is also great to ensure the config is conforming. I keep thinking we are trying to reinvent a worse wheel here.
I just recently replaced a bunch of YAML in a project with JSON. At face value the YAML still <i>looks</i> easier to grok, but I kept needing to periodically think about YAML<->JSON. At one point in the middle of yet again running JSON through a YAML conversion process to see how I would write something, it dawned on me that YAML wasn't saving making my life easier it was making it harder.
YAML in kubernetes works very well.<p>If yaml is not working for you have to search a serializer format that fit in your project.<p>There is not silver bullet.