No YAML

[mataug]

A respected senior engineer once told me "all configuration is code, if it modifies the behaviour of software, it needs to be testable"

Yaml is huge unintuitive PITA, I recently spent multiple hours figuring out the best way pass CLI arguments to a k8s cronjob via yaml. I only managed to solve the weird error messages after I stumbled upon the stackoverflow post linked in the webpage https://stackoverflow.com/a/21699210

> There are NINE (or 63*, depending how you count) different ways to write multi-line strings in YAML.

[rossy]

>> There are NINE (or 63*, depending how you count) different ways to write multi-line strings in YAML.

I hate to be the YAML defender, but I strongly believe that all of YAML's block and flow scalar types are necessary and that YAML's string handling is one of its killer features. Sometimes you need C-style string escaping with "" and sometimes you need verbatim strings with '' (same use-cases as verbatim string literals in programming languages, eg. for regexp.) Sometimes you need collapsed newlines and stripped trailing newlines (writing a description for your blog post in YAML frontmatter) and sometimes you need preserved newlines (embedding other languages like Markdown or Bash in a YAML document.)

A language like YAML should let you represent different types of strings in a way that's still human readable.

[mitchellgoffpc]

The lisp folks are probably wondering why it took us so long to figure out the whole “all configuration is code” thing haha

[Spivak]

There are actually infinite ways to represent multiline strings since you can explicitly specify the required indentation.

    some_key: >4
        This text has to be indented by 4 spaces.

[eyelidlessness]

I agree that YAML is code and I find it absolutely preposterous that there’s any notion otherwise.

[api]

Why is it used so much? Tooling? Stockholm Syndrome?

[paxys]

IMO "configuration languages are bad" and "YAML is bad" are two very different discussions. Mixing them up takes away from both.

Most of the complaints against YAML are really complaints against complex systems (Kubernetes, CI pipelines) which use it as their interface. The rest of the problems can be solved by quoting your strings.

YAML works perfectly well if it is (1) used for the right use cases rather than as a substitute for code and (2) paired with a linter or parser which handles its quirks.

[smt88]

> The rest of the problems can be solved by quoting your strings.

How do I get all of YAML's millions of other users to quote all of their strings?

What about programmatically generated YAML?

Also, you're entirely ignoring two other major issues: meaningful whitespace (making YAML hard to read and write) and multiple ways of doing the same thing (making it confusing).

[jahewson]

No, it’s the YAML, really.

[theonemind]

Developers seem to complain about anything that takes a little bit of memory and care. To a limited extent, that's not a bad thing--our brains have limits. However, when the benefits outweigh the costs, complaining about it is a bad thing.

Regular expressions are a good example. Developers seem to hate them. I find them easy and intuitive, and I'm not the sharpest tool in the shed. However, I will take some care to commit some stuff to memory and make some notes. That's it. When you know what characters are magic, know what the special characters mean, they're extremely straight-forward except when they're very complex.

Same thing with YAML. It's got a couple of rough edges, but the complexity carries its weight, and most of the difficulties go away if you bite the bullet and memorize it. Just commit those block chomping operators to memory, it doesn't hurt that much, then you can get on with your life and quit complaining about YAML and make it work for you.

[rdw]

YAML's not bad if you couple it with strong types. I used YAML _heavily_ and wasn't aware of any of the issues that the author mentioned because of the types. It doesn't let YAML automatically parse dates because the destination structure is either a date or a string or whatever, and that controls the parsing. It doesn't have the Norway problem because it knows whether a field is a boolean or not. I don't think it had the octal problem, not 100% sure though.

It's very good for non-technical people to edit because they are allergic to symbols and quotes and brackets and making sure things match. YAML's syntax let you write like you're a CEO sending agenda notes to a subordinate. You can easily switch between line-per-item and brackets-style and you do so whenever the readability is improved by doing so. It's highly intuitive somehow. You can pretty much turn someone into a config-editor just by showing them an example file, especially with syntax highlighting.

[UI_at_80x24]

>It's very good for non-technical people to edit

I strongly disagree. Being whitespace sensitive it's stupidly bad for non-technical people.

I don't like YAML for several reasons, to be honest I'd prefer an .ini based config setup or BSD styled "option=variable" config file paradigm. But I hate/despise/loathe the fact that YAML files are whitespace sensitive. That's a horrible choice. I hate python for it too, and avoid it's use whenever possible.

[zeroimpl]

Sounds like you are using a specialized parser. At that point, it’s not YAML.

[munificent]

I strongly believe that if Crockford hadn't refused to add comments to JSON that YAML, TOML, and other generally bad configuration languages wouldn't exist.

[mastax]

I don't hate yaml. It's a bit overcomplicated, a bit too cute, but it works. It doesn't leave a lot of room for additional complexity, though.

I've been using Ansible a lot recently. I like it a lot, most of the time. Its configuration files are YAML + Jinja2 templates + Python expressions. It works fine for the basics but when you push it quickly devolves into madness.

e.g. I had a task like this:

    - set_fact:
      foo_bar: >
        {{ item | map(attribute="something") | rejectattr("bar", "none") | flatten | select is any }}

Can you spot the error? The block scalar header `>` was missing the hyphen `>-`. YAML helpfully added a newline to the end of the template output. Python helpfully interpreted "False\n" as `true`.

I'm starting to think I should write Python modules for anything complex.

[XorNot]

This is exactly why I love Ansible. It has libraries to handle most of what I need, and most of what I need to do is just simple YAML expressions. When it gets complex though, it's first-class supported to drop into Python (or anything else which works as an executable script language) to get more control.

[bussierem]

> if SQL were built on YAML

Actually that's pretty nice compared to what we actually got:

https://schemahero.io/learn/tutorial/create-table/

[meepmorp]

Am I alone in thinking SQL by itself is easier to understand and use than all indirection people like to stick on top of it?

[inshadows]

That airport example... not sure if trolling.

[sellyme]

As I continue exploring that site I'm becoming increasingly concerned that it might not be satire.

[Zababa]

It's at least a great way to present it, way better than the single line string I usually see

[jmort]

The points in this post reminds me of the “configuration clock”[1]. Hardcoded -> configure file -> rules -> DSL -> Hardcoded. Maybe it should be the “configuration ouroboros”. Provides one explanation for why this config becoming code situation occurs over and over and what to watch out for.

[1] http://mikehadlow.blogspot.com/2012/05/configuration-complex...

[kbd]

Has anyone taken a look at Cue who can share any experiences?

https://cuelang.org/

It's mentioned on the site as an alternative to Yaml. Recently watched (~half of) this intro to it: https://youtu.be/fR_yApIf6jU

[harpratap]

I think it has the right take on configuration vs code but being a new language it's lacking a lot of basic things like package management, lot's of bugs and in my case - scaling issues.

[lytedev]

Been using it for the docker compose that builds my entire homelab (~30 services, fairly complex config) and I love it. It's saved me from some really nasty bugs a handful of times.

[johnisgood]

So what should one use for configuration? I am not going to use JSON because of lack of comments. A configuration file needs comments. TOML does the job for this well, I think.

[zkldi]

I've taken a massive liking to JSON5[1] recently for configs, but I've never really seen anyone else using it. Sucks, because I think it's really easy to read and write.

[1] https://json5.org/

[eyelidlessness]

TOML is fine. If you use JSON, almost everything has affordances for comments as keys (“//“: …) many also accommodate values ([“//…”]).

[krapp]

Lua is also good.

[dang]

One past thread and a bit:

No: Body: Wants: To: Write: – YAML - https://news.ycombinator.com/item?id=17360088 - June 2018 (71 comments)

Nobody Wants to Write YAML - https://news.ycombinator.com/item?id=24638883 - Sept 2020 (1 comment)

[skywhopper]

I find YAML, for all its flaws, to strike a lot better balance between usability and clarity than the alternatives. But whatever, people have their own preferences.

Ultimately, I don’t think it would be possible to avoid the sorts of problems people run into in any configuration language unless you have a strict type system on the config itself. But strict type systems on config have been tried and end up causing their own distinctive problems.

In the end people will complain about whatever their interface is to a complex system. They will always make errors in configuration and that will always be annoying.

[viraptor]

It's telling that with all those complaints, the website does not list any clearly better alternatives. (before someone says TOML: https://hitchdev.com/strictyaml/why-not/toml/)

[inshadows]

I don't think the point is another configuration language, much as it is to use real programming languages where appropriate. By using TOML you'd make the tasks where YAML is used even more cumbersome to write...

[soraminazuki]

It does, see L136-143.

[letmeinhere]

No flow style would be kind of painful at times. I like JSON5, because it has the two extra things I need beyond json: comments and trailing commas.

[bschwindHN]

After evaluating several config file formats, I settled on JSON5 for work projects. Only issue for me is that sublime text doesn't have highlighting for it, though the hjson highlighting from package control works well enough. I should write one for JSON5...

Ironically the file format for sublime highlighting plugins is in YAML.

https://github.com/hjson/sublime-hjson/blob/master/Hjson.sub...

[utf_8x]

Yeah, YAML is pretty bad but...

Is there really a better alternative? JSON is a horrible format for configuration, KDL is a cute idea in theory but in practice it makes me want to gouge my own eyes out, CUE is... weird, XML and INI should've been dead for years and TOML is just INI on meth...

At least JSON and YAML are somewhat interoperable (JSON is valid YAML* and converting YAML to JSON is trivial) and have native support in most modern languages...

* with some caveats

[Noe2097]

Taking a step back; this website is a piece of Art.

Its message stirs passions, it is written in the very formalism it talks about, and presented in a so unusually cumbersome way that it triggers the same kind of response (or questions) a surrealist setup do (essentially boiling down to: "why the f...?").

Thank you, it was delightful to experience.

[ghuntley]

Thank you for understanding the essence! :D

[johnsolo1701]

I just use JSON and related tooling instead. Because YAML is a superset of JSON, all yaml parsers also parse JSON.

[rp1]

If JSON supported comments it would be perfect.

[cryptica]

It's so strange that they did this because YAML looks nothing like JSON. The entire point of a standard is to impose constraints to ensure that different people will do things in the same way... That's how you achieve compatibility between different systems.

When you have a flexible standard which allows people to do something in many different ways, it defeats the entire point of there being a standard...

[zeroimpl]

From my experience, if you give pretty-printed JSON to a YAML parser, it will explode.

[marcinzm]

I just find all of this amusing in the world of big data:

- First there were bash scripts kicked off by cron

- Then there was Oozie which was XML and not those messy scripts

- Then there was Airflow which was code and not that messy XML

- Now there is Argo/etc. which are Yaml and not that messy code

The endless cycle of code-to-config-to-code continues.

[vinyl7]

Programmers love to find solutions to problems that don’t exist

[gregwebs]

The best setup I ever had going was cuelang (strongly-typed, JSON-like) compiling down to JSON or YAML as needed.

Using strongly typed programming languages (like how Pulumi uses TypeScript) also works well.

[csours]

Sounds like we need a YAML: The Good Parts talk

See also https://www.youtube.com/watch?v=hQVTIJBZook

[bmn__]

https://hitchdev.com/strictyaml/