Why YAML sucks?

Any language in which whitespace has syntactic value is intrinsically flawed.

Can't speak to your specific issues, but that's why yaml will always suck.

As a serialization format, agree 100%, but would Python really be better if it switched to braces?
- Yes, I think so. The downside with Python comes when refactoring the code. There’s always this double checking if the code is correctly indented after the refactor. Sometimes small mistakes creep in.
  
  It’s really hard to tell when Python code is incorrectly indented. It’s often still valid Python code, but you can’t tell if it’s wrong unless you know the intention of the code.
  
  In order languages it’s always obvious when code is incorrectly indented. There’s no ambiguity.
- Yes it would - look at optional braces for short if expressions in C family languages and why it's so discouraged in large projects. Terminating characters are absolutely worth the cost of an extra LoC
- would Python really be better if it switched to braces?
  
  Yes. A thousand times, yes.
- To be pendantic, it's level of indentation in Python that has semantic meaning, not whitespace.
- If nothing else it enforces readable code which I think is a good thing.
Haskell supports both semantic whitespace and explicit delimiters, and somehow almost everybody that uses the language disagrees with you.

But anyway, for all the problems of YAML, this one isn't even relevant enough to point out. Even if you agree it's a problem. (And I agree that the YAML semantic whitespace is horrible.) If YAML was a much better language, it would be worth arguing whether semantic whitespace breaks it or not.
- Yeah but Haskell is mostly used by mathematicians..
YAML sucks because, among other things, indenting it is not obvious.

In contrast, the only mistake of Python when it comes to whitespaces was allowing hard tabs, which makes it too easy to mix them if your editor is not configured.

Improper indentation stands out more than missing or unbalanced braces and it's really not an issue to delimit code blocks.
- Hard tabs are the only accessible option though. If you care about developers with a different vision capability than yours, the only correct indentation choice is tabs.
  
  If, because of bad vision, someone needs to crank the font size way up, it’s very possible that they might need to work with a tabstop of 3, 2, or even just 1 space.
  
  With tabs, this is user configurable. With spaces it isn’t.
Not any language. I code professionally in F# which has semantic whitespace and it has literally never been an issue for me or my team. In contrast to Python, it’s a compiled language and the compiler is quite strict, so that probably helps.
It's the only time that tabs Vs spaces really riles me up. So annoying when everyone has different tab lengths
I now use Scala 3, and very happy with syntactic whitespace (combined with an intelligent compiler)

Can people stop hating on shit?

FOR FUCKS SAKE, negative reinforcement dopamine has RUINED THE FUCKING NET.

EVERYWHERE I GO there's someone bitching about something, hate circlejerks are unbelievably popular, people just love to hate on stuff.

You're ruining your thought patterns with all these social media negativity bullshit.

Fucking TOML users hate on fucking YAML fucking C++ users hate Rust fucking Rust users hate literally everything under the sun and are insufferable to work with

EVERYONE, fucking CHILL

Can you stop hating on haters? Thanks 😄
stop hating on rust devs
Yeah TBH I like yaml. Sure its not the best ever, but its not the worst it could possibly be.

For config its not terrible. For ansible playbooks its again... not terrible.

Why is everyone always hating on something which is just kinda mid.
- Config is fine, but Yamls biggest problem is people use it to describe programs. For example: playbooks. For example: CI steps.
  
  If YAML wasn't abused in this way it would have a lot less hate.
- I dream of a life where I use YAML but all my configs are stuck in XML. People can complain but there's always worse options.
No seeds no stems no stress my guy. The Internet is a great place for complaining. Readers can downvote and move on, everyone gets what they want.

Programmers hate everything. You could design a spec which serenades you with angel song and feeds you chocolate dipped grapes and someone would be like: This is awful, my usecase is being a dog.

Sure there aren't many things that are universally loved. I mean I can't really think of anything that doesn't have some flaw.

But that doesn't mean everything is equal! What would you rather program with, Visual Basic or Go? PHP or Typescript? If you polled people there are obvious winners.
- Hey would you rather build from wood or steel?
  
  What glue is better: 2 part epoxy or PVA?
  
  Do you prefer soap or bleach as cleaning agent?
This comment is underrated, even if it rises to the top of all comments.
- Pleased to have touched your life with levity, stranger.
I write my specs in C++

https://noyaml.com/

That is amazing.

I don't know what I just read.

If my website ever gets married, I'm going to invite this website to stand next to it as a bridesmaid - because it makes my website look pretty by comparison.
Sadly, unreadable on mobile. Text doesn't word wrap, dragging to pan it is annoying and makes the keyboard show up.
Most of the stuff here can be avoided by using quotes for strings..

Because people over use it. YAML is pretty good for short config files that need to be human readable but it falls apart with complex multi line strings and escaping.

I think there are much better clearly delimited for machine reading purposes formats out there that you should prefer if you're writing a really heavy config file and, tbh, I think for everything else .ini is probably "good enough".

At least use TOML if you like ini, there is no ini spec but TOML can look quite similar.
- Strong agree. It's also the absolute best at expressing really long documents of configuration/data.
I agree - YAML is not suitable for complex cases that people use it in, like ~~Terraform~~ and Home Assistant. My pet peeve is a YAML config in a situation that really calls for more abstraction, like functions and variables. I'd like to see more use of the class of configuration languages that support that stuff, like Dhall, Cue, and Nickel.

There is another gotcha which is that YAML has more room for ambiguity than, say, JSON. YAML has a lot of ways to say true and false, and it's implicit quoting is a bit complex. So some values that you expect to be strings might be interpreted as something els.
- For those highly complex situations is Lua still viewed as the ideal solution? Lua is sort of legendary for game configuration and seems to strike a good expressiveness/accessibility balance for modders and the casually technical.
- What YAML does Terraform use? HCL is similar but different enough to YAML.

Following along with the style of your own post: YAML doesn't suck, because I feel so.

Thanks for asking.

I don’t like YAML because it’s overly complicated. The specification is like 80 pages long. How the hell did they think that was a good idea?

JSON on the other hand is super simple. It doesn’t do more than it needs to.

Just compare this: https://yaml.org/spec/1.2.2/

With this: https://www.json.org/json-en.html

The entire JSON specification is shorter than just the table of contents of the YAML specification!

Another thing I like about JSON is that you can format it however you want with the whitespace. Want everything on one line? Just write everything on one line!

If data can be represented as a JSON, then there’s generally only one way to represent it in JSON (apart from whitespace). In YAML the same data can be represented in 1000s of different ways. You pick one.

I will never forgive JSON for not allowing commas after the last element in a list.
- That lack of trailing comma has been the bane of my existence.
This is the major reason for me. I really liked yaml, because it is way more readable to me than JSON. But then I kept finding new and more confusing yaml features and have realized how over-engineered it is.

Yaml would be great language if it had its features prunned heavy.

One pattern I've noticed is people seeking a language that's better than {JSON,XML,INI,etc} at wrangling their slightly complex configuration files, noticing the additional features and type support offered by YAML, and assuming it will be a good solution.

Then, as their configs grow ever larger and more complex, they discover that expressing them in YAML requires large sections of deep nesting, long item sequences, and line wrapping. The syntax style that they saw working well in other places (e.g. certain programming languages) breaks down quickly at that level of complexity, making it difficult for humans to correctly write and follow, and leading to frequent errors.

YAML doesn't suck for small stuff, IMHO. (But it is more complex than necessary for small stuff.)

For things likely to grow to medium-large size or complexity, I would recommend either breaking up the data into separate files, or looking for a different config/serialization language.

To paraphrase: There are two kinds of markup languages. Those that people complain about and those that nobody uses.

There is no silver bullet that will work perfectly for all use cases and we also don't want to use 100 different tools. So people use things that aren't perfect. But they're good enough. I don't think YAML is perfect and I still use it, because people know it and there are tons of tools already available.

But it's not a markup language.. It's for data serialisation..
- I remember the time when YAML meant Yet Another Markup Language.

I think TOML should replace YAML for config files, it is much clearer, easier to parse for a human.

Depends on the data structure. If you want to save a table of sorts, you're getting a bunch of unreadable [[[]]] nonsense.

For flat structures it's great though.

I don't like a thing, fellas. With that being all I've told you, please explain why I don't like that thing.

Tons of people making Python comparisons regarding indentation here. I disagree. If you make an indentation error in Python, you will usually notice it right away. On the one hand because the logic is off or you're referencing stuff that's not in scope, on the other because if you are a sane person, you use a formatter and a linter when writing code.

The places you can make these error are also very limited. At most at the very beginning and very end of a block. I can remember a single indentation error I only caught during debugging and that's it. 99% of the time your linter will catch them.

YAML is much worse in that regard, because you are not programming, you are structuring data. There is a high chance nothing will immediately go wrong. Items have default values, high-level languages might hide mistakes, badly trained programmers might be quick to cast stuff and don't question it, and most of the time tools can't help you either, because they cannot know you meant to create a different structure.

That said, while I much prefer TOML for being significantly simpler, I can't say YAML doesn't get the job done. It's also very readable as long as you don't go crazy with nesting. What's annoying about it is the amount of very subtle mistakes it allows you to make. I get super anxious when writing YAML.

YAML works great for small config files, or situations where your configuration is fully declarative. Go look at the Kubernetes API with its resources.

People think YAML sucks because everyone loves creating spaghetti config/templates with it.

One reason it tends to become an absolute unholy mess is because people work around the declarative nature of those APIs by shoving imperative code into it. Think complicated Helm charts with little snippets of logic and code all over the place. It just isn't really made for doing that.

It also forces your brain to switch back and forth between the two different paradigms. It doesn't just become hard to read, it becomes hard to reason about.

I didn't use yaml much while it was gaining popularity, and therefore didn't pay much attention. But this article really made me pay attention and now I distrust anything that uses yaml in any capacity.

https://ruudvanasseldonk.com/2023/01/11/the-yaml-document-from-hell

Great link.

It sucks the same way Python sucks. Some people just really don't like indentation-based syntax. I'm one of them, so I dislike both formats. However, if you groove on that sort of thing, I don't think YAML is any worse than any other markup.

Oddly, I get along with Haskell, which also used indentation for scoping/delimiting; I can't explain that, except that, somehow, indentation-based syntax seems to fit better with functional languages. But I have no clear argument about why; it's just an oddity in my aesthetics.

You can't say python's whitespace usage is as bad as yaml's. YAML mixes 2 and 4 spaces all the time. Python scripts don't run if you write this kind of crap.

And whitespaces is really just the tip of the iceberg of YAML problems...
- YAML mixes 2 and 4 spaces
  
  I think that's a user thing and it doesn't happen if you have a linter enforce 2 or 4.
- YAML mixes 2 and 4 spaces all the time. Python scripts don't run if you write this kind of crap.
  
  Sure it does. You only need to be consistent within a block. Python's syntax is ridiculous and solves problems that basically don't exist.
  
  All of my java/kotlin/rust/etc. code is trivially well formatted and can be done by my editor. Moving code blocks is trivial. Refactoring is easier when I didn't need to hand -format the code just to make it work.

But.. Yaml ain't markup language..

I hated yaml with every fiber of my being when first had to use it, but I really wanted to use HomeAssistant and see what I could do with it. I hated it a bit less when I started using docker compose. I started loving it when I started using it as a way to explain json to non-programming IT types, trying to explain it without braces and brackets seems to get across easier. I guess its more human readable, but as a result formatting has to be spot on (those indents and spaces replace the need for brackets and braces).

One useful trick if you truly hate it but need it, write it in json, then just use a converter to change that into yaml.

Fun fact, since YAML is a superset of JSON, any JSON is a valid YAML. You can still use pure JSON.

I used to think json was the best until I found json lines or line delimited json. Thank me later. I use it all the time. You can append until you’re blue in the face. It’s great for log files. Each line is a valid json file.

I like yml. Clean to read, easy to use, supports comments.

and no possibility of (a lack of) trailing comma's. Unless you use JSON inside Yaml, you heathens!

YAML had comments and trailing commas, therefore it's objectively better than JSON. If you want a compromise solution that mostly looks like JSON, try JSON5.

it does what it needs to do: i don't think it's necessarily bad.

it's for data not programming and it handles complex structures cleaner than json

My issue with it arises when data is not interpreted as I expected, like because of weird white space issues for example.

I don't hate YAML, but it has the same issues languages like PHP and JS introduce...there are unexpected corner cases that only exist because the designer wanted the language to be "friendly"

https://www.bram.us/2022/01/11/yaml-the-norway-problem/

Sorry, what's confusing the fact that "Hi my name is {$this->name}" works and "Hi my name is {self::name}" is unintelligible gibberish! /s

We all know it sucks. I have no idea why people use it instead of anything else. My workday is jammed with fucking ansible which, while also being so ghetto that we were easily doing more with less in 2002, uses So.much.fucking.yaml . Just when you think ansible couldn't get more clunky and useless and slow, it also is configured in yaml.

It's inconsistent and annoying. Expressive, yes. Gets it's job done, yes. Absolute nightmare of a spec, YES.

The fact that JSON is a subset of YAML should tell you everything about how bloated the spec is. And of course there's the "no" funny things.

Personally, my favourite way to write configs was using lua (because it was already part of the project so why not), but JSON does fine.

I like TOML: https://TOML.io

It's a rube goldberg footgun

YAML is fine if you use a subset (don't use the advanced features - not like you know those anyway) and use explicit strings (always add " to strings), otherwise things may be cast when you did not intend values to be cast.

Example:

country: NO (Norway) will be cast to country: False, because it'll cast no (regardless from casing) to false, and yes to true.

country: "NO" should not be cast.

People are working on making S-Expressions a standard: https://datatracker.ietf.org/doc/draft-rivest-sexp/

Note: This is just a draft, but improvements have been happening since 2023.

I probably won't like the parentheses, but I think I'll take it over yaml/json/whateverelse.
- That appears to not support comments. How they made that mistake after JSON is a mystery.

I think much of the issue with YAML is that it's often paired with bad editors. You need a way to manage the whitespace, collapse sections, etc. Notepad doesn't cut it.

I wish s-expression was a popular alternative. It's readable without the yaml issues.

Someone's working on a standard! https://datatracker.ietf.org/doc/draft-rivest-sexp/

Yes, they could've just used JSON. Totally pointless waste of time.

JSON does lack comments. And numbers that are not 64 floats.
- TFB, the numbers are not defined as 64 bits floats.
  
  They are just not defined. At all.
- Readability in general sucks
- There's a spec for json with comments. It's better than yaml in every way.
- There's a lot of JSON parsers that don't mind to see comments there, just ignore them. And there's also the "_comment" / "$comment" thing.
- And lack of trailing comma's
So Poe's Law and all that... I really hope you're being sarcastic because having non-technical people hand edit JSON is a nightmare. It's also quite annoying to read without a lot of extra whitespace which most editors that'd help less technical folks omit... and comments to help highlight what different things mean are hacky, hard to read, and actually read as data.
- No, I'm kind of serious, the comment situation is already solved in JSON... about the rest yeah, Yaml might be easier but the different isn't that much. Non tech people can't edit Yaml properly either so.

I'd rather edit YAML config files than XML config files. I don't think that it's especially bad.

IIRC it doesn't allow trailing commas in lists, which I'd like to have, but JSON's the same way; it's a common characteristic to have.

Somehow it’s clunky to use.

huh?

I find developing GitHub CI in YAML clunky.

I don't find configuring a simple service via YAML config, with a preset showing me and explaining what I can do clunky.

It's docs are garbage, but the language is quite simple and human readable even for non-techies. I think it's a bit too easy at times, resulting in people just kinda winging it

Yaml is fundamentally the same as the json and xml it has mostly replaced (and the toml that didn't manage to replace yaml)... it's a data serialization format and just doesn't have any facility for making abstractions, which are the main tool we human use to deal with complexity.

JSON and YAML aren't the same as XML. The attribute/child distinction in XML, and the fact that every object has a tag name associated with it, make it a PITA to map into the data primitives of any programming language I know.
- Yes, XML is different than JSON and YAML, but it's not particularly easier or harder to manually read/edit than JSON or YAML are (IMO the are all a pain, each in its own way).
  
  If you want to look at it from the programmer's side (which is not what OP was talking about)... marshalling/unmarshalling has been a solved issue for at least 20yrs now :) just have a library do it for you (do map json/yaml properties to you objects manually?).
  
  You don't need to worry about attributes/child elements: <person name="jack" /> and <person><name>jack</name></person> will work the same (ok, this may depend on what language/library you pick - the lib I used back in the day worked either way).
  
  If anything, the issue with XML is all the unnecessarily complicated stuff they added to its "core" (eg. CDATA, namespaces, non-standalone documents, ...) and all the unnecessarily complicated technologies/standards they developed around XML (from Xinclude to SOAP and many others)... but just ignore that BS (like the rest of the world does) and you'll mostly be fine :)
Abstractions aren't concrete and all of these standards you're referring to are concrete data serialisations. You may be interested in CUE which captures this concept in its design.

If YAML and JSON were gripping my hands for dear life, dangling off of a cliff...

I would let both drop into the abyss so I could spend more time with INI.