# I guess you could put ["YAML"] if you need it as an array and not a string
no.body.wants.to.write=YAML
Easy to type, is on a single line, only breaks once you're so many layers deep that you need to scroll horizontally - but let's be real - if that happens the config isn't the problem but why is your program so complex? is the problem.
Drawbacks of this are when the program is inconsistent. Was it `nobody.wants.to.write` or `no.body.wants.to.write`? Or alternatively, why is it `nobody.wants.to.read` but `no.body.wants.to.write`?
It's a bit of a strawman, since none of your examples actually resemble valid config files and you're forcing them all to have the same indentation, when significant whitespace only matters in YAML.
none of your examples actually resemble valid config files
Neither does the YAML one? So?
you’re forcing them all to have the same indentation
I don’t know about you, but I always pretty-print JSON, just like I always indent my code no matter which language I’m using.
In fact that’s one of the arguments in favour of significant whitespace -- you’re going to be indenting anyway, so why bother with the brackets? It’s not an argument everyone buys, but everyone still indents their code.
> > you’re going to be indenting anyway, so why bother with the brackets?
> Because brackets are explicit. Whitespace is implicit and difficult to distinguish without editor support.
I'm with parent on this one. Most people who complain about python's reliance on indentation still indent their code, and rely on the visual & editor hints (ie. they're profoundly confused when they muck up their indentation, but their brackets are still correct).
But I digress.
Whitespace is explicit in some (markup) languages, and there's nothing *plicitly wrong with that. If you're trying to do any kind of editing of a (markup) language that relies on sensible indentation with an editor that doesn't understand whitespace then you've probably got bigger problems.
> Whitespace is explicit in some (markup) languages, and there's nothing plicitly wrong with that.*
Whitespace is never explicit. It only exists as the gap between other characters. You only perceive its absence.
> If you're trying to do any kind of editing of a (markup) language that relies on sensible indentation with an editor that doesn't understand whitespace then you've probably got bigger problems.
Which is why they should not be used for configuration files.
More seriously, the earlier comment complained that the indentation for the non-significant-whitespace examples was artificial. I’m saying it’s not artificial because in practice you would indent it.
That, not too mention how often do you actually write data files by hand? Maybe a small sample file for testing, but beyond that all data is going to be read in from files or come from an API.
JSON is not bad to write by hand. Simple XML isn't too bad either, but I still prefer JSON.
JSON doesn't have comments. If I want to know why a config has a particular value, I can write a comment to explain it in YAML or xml, just like I would do in code. Lack of comments is the primary reason I would not use json for anything that needs to be written or read by humans.
I want to write YAML because I don't want my configuration to look significantly different in go, java, ruby, or any other language my organization may use in the future.
Xml is fine. Json is fine. Yaml is fine. Yes, they have warts. That's fine too.
For most things lately I've been using TOML because it gets me that, and it's a relatively simple (to a human) standard. Combined with there being parsers and emitters in just about every language now, it's a great option. You get sections in the config that map easily to native data structures in the languages, good string handling, can create a few more advanced things like arrays (really useful for adding multiple ports or listening addresses, etc.).
I do still use YAML on the rare occasion where i just don't like how the TOML ends up looking[1]. My plan with that example is to eventually make a more simplist DSL that can handle the usecase, but my first attempts didn't produce anything I liked.
I like YAML. It's ok if you don't. It's ok that I do. Want to use TOML? Awesome. Want to use JSON? Go for it. I prefer YAML, it works for me and I'll keep using it until something better comes along that I like.
Preference is preference. Stop acting like it's not. This page might have been "Nobody wants to use VI" or "Nobody wants to use Emacs" or "Nobody wants to use [insert thing I hate here]"
So lobby those projects to add more support. Heck, make a PR to add the serialization language of your choice. Start coding. If they don't want patches for "[insert data serialization formation here]", maintain your own fork.
FWIW CloudFormation added YAML, which was a vast improvement to usability IMO over where they started. Want CloudFormation to support something else? Lobby through your AWS account rep for what you want supported.
I agree with what you are saying but the boat has sailed. Just like decisions with the SMTP protocol in the early years where folks can fake the FROM field thus causing the issues we experience every day the same is true with devops and yaml. Forever:Drowning:In-YAML.
CloudFormation supports json too. And if you really want to use json for docker or kubernetes you can use a yaml cli. `docker-compose up -f <(npx js-yaml docker-compose.json)` or something like that.
Requires Javascript to even start showing the text. That "live" editor trick is neat, but pretty unnecessary to transmit the message, if you ask me. Also there are some good-old links that are not even clickable. Weird choice of tool for the job.
Just as YAML provides no validation document, intellisense or type safety this website is designed to be a hindrance. It's part of the message to make the experience more real. I do accept PRs tho so mash the octocat.
> We replaced 1,000 lines of YAML with 10 structs ...
I looked, but target URL didn't spell it out, and I lack sufficient domain knowledge to dive into the repo to find it -- but I'm curious as to how big, and indeed how complex, those 10 structs are.
It seems disingenuous to swap units mid-sentence when comparing size or complexity.
My gut feel is the set of people who could understand thoughtfully designed YAML should be larger than the set of people who could understand thoughtfully designed structs (+ wrappers?).
In a nutshell, they got rid of a custom programming language they had inadvertently created via YAML and text/template. Their YAML models were effectively written in a Turing-complete language composed of YAML and text/template directives. They had been heavily abusing the FuncMap type in text/template.
Thanks, and yes, I did read through that page. Lots of coloured text that tantalisingly looked like links but weren't, and a lot of broken images/slides.
It sounds like it wasn't a problem with YAML per se, but their misappropriation of text/template and wrangling YAML to be something other than a configuration tool. It feels similar to if I were to complain about the shortcomings & complexity of the jinja2 constructs I make within my YAML.
Ah yes but please revisit this problem space from the perspective of a consumer of YAML. Ops folks are drowning in it. The industry can and should do better.
YAML is not 100 percent awesome, but it's machine consumable, not too hard to edit by hand, and preferable (in my opinion) to a plethora of application specific DSLs with different requirements for curly braces, semicolons and assignment operators.
One of the lovely bits I ran into recently is whether a given YAML parser interprets a value as a string or not (for example) is entirely up to the parser, and there's nothing you can really do about it in the syntax. Quoting is a useful hint, but the parser doesn't have to take action as a result. !!str is another useful hint, but str is kind of up to the parser. My favorite related bug that shows the kind of shenanigans that simply using YAML results in: https://github.com/kubernetes/helm/issues/1707
Did I read correctly that YAML is a superset of JSON?
> This means that, in theory at least, a YAML parser can understand JSON
Does anyone have experience with this? It seems counter-intuitive at first, but Google agrees, and I don't know enough about parsers to say it's wrong. Can you really feed pretty much any JSON file into a YAML parser and get back a valid and correct, properly formed data structure?
Yes, the only problem I have encountered was some version of pyyaml that couldn't deal with \t characters (which are valid in JSON but not YAML 1.1, 1.2 fixed this).
I don’t need a “thought” emoji to read your first line, I don’t need the finger pointers to see where I should read next, it’s condescending and terribly ugly.
Because it's an emotional rant that was shipped in <15mins. It's not designed to please. It's designed (inc UX of a code editor) to be an over the top 'too close to reality' realistic experience for any engineer in the devops arena.
PS: I accept PRs to make it work better on mobile including accessibility. Send PRs.
I love YAML and I don't care what anyone else thinks. For simple config files, I use INI (could use TOML, I suppose). For anything beyond that, I use YAML. It's easy to read, parse, write, and maintain. I just use the subset that's relatively straightforward (no & ! --- sigil vomit).
use it almost every day. it's an ugly little notation with super-limited utility, but when JS gets its act together, we can finally abandon it forever.
I am really beginning to hate programmer-centric tooling. It has turned all of us into these miserable, cretinous engineering snobs. It seems impossible for anyone to contemplate why people would choose to work differently than them. Zero empathy. Fucking pathetic.
Make software hard again, I say. Treat the compiler like you would treat your dominatrix. Life would be so much better that way!
The second hit is a google+ post wailing “arrrrgh, somebody reinvented borgcfg for Kubernetes” :)
I’m guessing the switch to YAML, even though it might be a bit tedious, was an explicit reaction to the fact that the ultra-programmable borgcfg turned out to cause some big headaches.
HOCON, from the Scala community, is great. It’s specifically designed for configure files (as opposed to data transfer) so has a bunch of features that make that easier.
