I feel that Yaml sucks. I understand the need for such markup language but I think it sucks. Somehow it’s clunky to use. Can you explain why?
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.
That’s part of the problem. Different number of whitespaces indicate different nesting levels and the YAML spec does not enforce them. These two horrible YAMLs are valid and are not equivalent:
a: b: - c - d - e f: "ghi"a: b: - c - d - e f: "ghi"So it’s easy to enforce locally but you don’t have to. And it’s easy to see indentation on modern IDEs and you can even make your indents rainbows and collapse structures to make it easier to see what’s going on, but I guess since some people want to write it in vi without ALE or a barebones text editor, it’s bad? Like there are legit reasons it’s bad, and other people have mentioned them throughout the thread, but this seems like a pretty easy thing to deal with. I work with ansible a bunch and YAML rarely is where my problem is.
Jesus, just what I want to do with the devops team - spend a few weeks standardizing on an editor and configuring them to edit yaml.
A few weeks? How do you stay employed? How do you even feed yourself at that pace? Blocked on making a sandwich, I’ve got the wrong type of bread.
It’s three lines in an editor config file to standardize the indents across any editor: https://editorconfig.org/
In vscode, adding two extensions is all I need:, yamllint (if you don’t use linters, I don’t know how you do your job in any language) and rainbow indents. Atom had similar ones. I’m sure all IDEs are capable of these things. If you work at a place that forces you to use a specific editor and limits the way you can use it, that’s not YAML’s fault.
At a certain point, it’s your deficiencies that make a language difficult, not the language’s. Don’t blame your hammer when you haven’t heated the iron.
You know how many editor plugins I need to work with json? None.
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.
deleted by creator
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.
deleted by creator
Can you stop hating on haters? Thanks 😄
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.
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.
One nice thing about XML is that there’s an official way to link to the schema from within the document. If you do that you can easily automatically validate it, and even better you get fantastic IDE support via Red Hat’s LSP server. Live validation, hover for keys, etc.
It’s a really nice experience and JSON schema can’t really match it.
That said, XML just has the wrong data model for 99% of use cases.
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.
What’s wrong with using YAML for CI? I mean, I use it for Gitlab CI, the underlying script it runs is just Bash.
You’re doing it right by avoiding as much of Gitlab’s CI features. I’ve seen versions where scripts are inlined in the YAML with expressions in random rule fields and pipeline variables thrown all over the place. And don’t get me started on their “includes” keyword, it’s awful in practice, gives me nightmares.
Then I write a Kubernetes manifest in YAML with JSON schema validation and the heart rate goes down again.
Right, so you just have a single step and then hand over to a proper script. I’ve seen many people try to put much more complex logic in there before handing over to a proper language.
deleted by creator
stop hating on rust devs
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.
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 tocountry: False, because it’ll castno(regardless from casing) tofalse, andyestotrue.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.
That’s a thorny question: Do comments need to be in the base standard, or can that be offloaded to those building on it? It doesn’t look like it would be hard to have
(comment "foo bar baz")in an expression and have a re-parser throw that out.Is the complaint that no two groups of people will use the same comment standard if left to their own devices? It’s not like the other data from different sources will always match up. What’s one extra, and fairly easy to handle SNAFU?
That said, yes, I think I’d be more comfortable knowing there was an accepted comment format. The aesthetic seems to be Lisp-like, and I notice that the Lisp comment marker, the semicolon, is currently a reserved character, that is, it’s illegal to use it unquoted. Maybe they’re thinking of adding that at some point.
It doesn’t look like it would be hard to have (comment “foo bar baz”) in an expression
That is pretty much what the official “solution” is for comments in
package.json- add"//": "foo bar baz"keys to dictionaries and NPM will ignore them.In practice it’s terrible. You need real comments.
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.
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.
Most of the stuff here can be avoided by using quotes for strings…
Sadly, unreadable on mobile. Text doesn’t word wrap, dragging to pan it is annoying and makes the keyboard show up.
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 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.
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.
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 :)
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.
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’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.
“Why does YAML suck?” is a question. “Why YAML sucks” is an explanation.
I don’t like a thing, fellas. With that being all I’ve told you, please explain why I don’t like that thing.
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.
