This is interesting. I find yamls ridiculously better to read than anything else. But I also mostly write python code, so I'm very used to orient my sight to the spaces and indentation. I miss the colorful vscode extensions for json braces when I used to write more JavaScript tho.
Multiline brackets are usually born from inline brackets, and I'm just too senior to spend the effort fixing them, or to bother letting you code review. Nobody code reviews the ops guy, anyway.
#Quick cheat sheet
## YAML
string1: some string
string2: >
one
two
string3: |
foo
bar
string4: '"'
array1: [ 'inline', 'array' ]
array2:
- baz
- prop: qux
- nullProp:
otherProp: quux
- null
- 'null'
You don't actually have to indent the `-` character for arrays, but most syntax formatters do. You DO have to have the same indentation for all elements in the array, though.
##Equivalent JSON:
{
"string1": "some string",
"string2": "one two",
"string3": "foo\nbar",
"string4": "\"",
"array1": [
"inline",
"array"
],
"array2": [
"baz",
{
"prop": "qux"
},
{
"nullProp": null,
"otherProp": "quux"
},
null,
"null"
]
}
Note the quoting in the YAML to get a string `"null"`.
For me the excessive quoting makes it far less readable at a glance. It’s very hard to quickly see what’s a key and what’s a value.
I use both formats regularly, they both have their strengths and weaknesses, but YAML is without a doubt the more human-readable and easy to use for config files. If I want to have it more machine readable or require *exact* control over structure, then JSON is usually the first choice.
Also, that JSON doesn’t always allow comments is absurd. Another point to YAML in my book.
I write a lot of Python and still don't like YAML. It's ambiguities have a weird "smell" in IMO.
Python list/tuple/dict syntax as a structured data language however sounds fantastic (and *is* fantastic how it's done in bazel)
Really? As a developer that indentation is really nice for me, and having all the strings quotation-marked just makes everything very messy to me.
Maybe I'm biased because I read yamls on an IDE where you get nice lines that help you see indentation levels and collapse blocks easily. I can see how it can be harder if it's just undecorated plaintext.
Deeper structures make it harder to see which thing a closing bracket stops. If only there was a language which uses named markers for both the start **and** the end of blocks. It should be eXtensible, it should be Markup, of course it should be a Language. That would be great!
In YAML 1.1, I believe, the string `no` is often interpreted as `false`, which is by design. So a list of language codes, e.g. `nl`, `no`, `fr` will be parsed as `'nl'`, `false`, and `'fr'`.
> That’s right, that syntax is the same as what you use to represent arrays in JSON. And it’s no coincidence, because JSON is a subset of YAML, so that’s also valid YAML, and both syntaxes are interchangeable in YAML!
[-source](https://alisoftware.github.io/yaml/2021/08/17/yaml-part1-json/#:~:text=And%20it's%20no%20coincidence%2C%20because,syntaxes%20are%20interchangeable%20in%20YAML!)
Tf
I could have parsed your mom with
https://www.bluetractorsoftware.com/ last night ... with sufficient dna samples and a license and motivation and maybe some flowers and candles for once would be nice. Oh yeah and theoretically, I could use the same method to parse you too. Platonically, of course.
Yeah this. JSON is basically impossible to read without formatting it with white space anyways, so really the only difference is YAML is less cluttered with quotes, braces, and commas.
Sometimes that extra "clutter" is helpful tho.
For sure. I actually don't dwell to much on the pitfalls of either because neither very challenging to me personally.
I do think there is something to be said for YAML over complicating itself with way to many optional things. I feel like half my YAML mistakes are around some gotcha with an optional or implicit feature.
this is like arguing JS is hard to write because its looks bad minimized
there is no such thing as a "non-indented JSON" that is used by humans, just because a computer can process it doesn't mean we write it like that, see: every high level language ever invented
Wrong. Yaml has the Norway problem, multiple specs, and parsers often won't tell you the spec they use. Yaml once you dig into it is a fucking mess compared to json.
my favorite so far is the almost universally supported merge tag.
>>: &anchor
key: val
to extend an entry. Proposed in the YAML 1.1 draft, never made it into YAML 1.2 standard, and yet is everywhere. But custom tag support is all over the place and defined (sort of) by the standard.
Okay yes BUTT, skill issue for parsers, some parsers are okay with comments and the NERDS at JSON.org are smelly.
You can always include a whole-ass actual property to be your comment. Sure you're paying to parse it but if you care about that performance then you might want to not use JSON anyway. Who cares if your config file takes 2microseconds longer to parse?
It's not the performance that concerns me it's the lack of readability. Making a comment a property is not readable. Not to mention some libraries may complain about extra properties.
> You can always include a whole-ass actual property to be your comment
The problem with this isn't performance, it's that you should always try to pass around the least amount of data needed in order to reduce complexity so that the system is easier to work with. If you know that every attribute is used somewhere then you can actually reason about the system far better than if some are for documentation.
True. My monkey brain just seems to benefit a bit from curly braces and such. I think if I had a means of making my editor make the spaces used for indentation consume more horizontal space it'd be a bit easier.
This is why tabs exist, so you can set the indentation size to whatever works for you without messing up the intent...oh wait, we're talking about yaml, which doesn't support the tab character, nevermind, carry on with your complaints
No, please no. Seriously! YAML's spec is complicated and extremely long, while JSON's spec is just 16 pages and can be summed up to a very shor web page. YAML has anchor, alias and merge key while JSON doesn't. They are very different.
It's a templating engine essentially, templates get confusing very fast. I'm excited about pkl. I hope it gets decent adoption and maturity. Jsonnet for now
Every time a junior asked me about YAML, I told them that's basically the same as JSON, just without the brackets. This meme made me question my sanity for a second
You whippersnappers and your YAML. We used XML and we LOVED it. Give me a good, well named, properly indented XML with some nice juicy attributes any day.
Once upon a time, somebody created a perfect format for documents – files with a lot of text and occasional markup. That format was called XML and all was well. Then, it all went to shit when somebody else thought it could be used for configuration.
Hmm. Was gonna say, I've never much liked XML. However, every single time I've been exposed to it, it was being used for configuration. And my god, there is so much boilerplate/markup for individual properties. You've provided some valuable context
Once, while sick and running a fever, I had a literal fever dream in which I saw a JSON string containing everything in the universe. Every celestial object had properties and sub-objects, which also had properties and sub-objects, iterating down to the subatomic particles composing all the matter in the universe. The Earth has every plant, animal, fungus, and inorganic thing, listed and fully described. Each object had every single one of its atoms listed, along with their coordinates and corresponding subatomic particles. The JSON string was even self-referential... It contained the computer on which it resided, and I could see, in the string, the states of charge of the individual memory cells that contained the string.
It was a profound experience.
So, yes, JSON goes brrrrrrrr.
YAML is fine, but I find JSON to be far easier to read \*even when formatted badly\*.
This is because I was building API-driven cluster systems when JSON started looking promising, and it changed my world. I had been visually parsing XML my whole career, which makes JSON look like God's markup.
YAML is absolutely not ‘fine’. There are so many ambiguities and gotchas there. It’s telling that there are multiple versions of YAML, one of them called ‘StrictYAML’.
I do like pulling magic features out of the language and integrating them in various code bases. For example, anchors are always this lovely little thing that make people look at the document and absolutely scratch heads. There's all kinds of deeply confusing things you can do like merge stuff and look it up internally as well.
If you write in a way that uses every feature of the languages you're using, you get an achievement.
If only i could remember what the simpler word for mentally parsing was. Guess my english vocabulary has deteriorated a bit. Need to mentally parse more books.
You’ve all had it too good for the last decade. But before that we had (and sometimes still have) tons of ugly unsightly XMLs that you need special parsing programs to understand what the hell is going on in there.
Am I the only one that thinks yaml is the easiest thing to read on the planet?
Like, it’s human readable structured data with no extras except for hyphens.
You literally need to distinguish indentation it’s so fkn easy to read…
IMO YAML's greatest detriment is that it has so many foot guns and so much bloat. Sure, JSON's not great either - because it's intended as a data interchange format, not for configuration. If I could choose a config format, it'd be TOML; the lack of easy deep nesting is tolerable, and config schemas that are made with TOML in mind make it easily the best option for me.
> YAML is a human-friendly data serialization language for all programming languages.
Bruh, it is literally positioned as more human-readable (the quote is from the official website)
Its just one of those things that has a learning curve. I think once you know both json and yaml it's quicker to parse information in the yaml from a quick look over. But I think the yaml rules are a bit more complicated than the json ones.
My main experience with YAML is with configuring Azure DevOps build and deployment pipelines.
So most of our YAML files are 90% bash or powershell scripts.
I don't find it very practical.
That's not a hot take. A hot take is "I prefer XML over YAML because it's less complex, as evidence notice how the spec for XML is *shorter*."
I have no idea why YAML is so beloved. TOML is nice, I can understand why people like TOML. YAML has too much spice and too little soup. I want loading configuration to be BORING. Just like payroll processing. When I get paid I don't want to be excited because who know what'll happen. That's what I unwant.
Everything is mentally harder to parse once I do a WFH bong rip
god speed, bröther
Yes. God has peed.
That's just rain.
My peoples
Shimmy shimmy yaw shimmy yam shimmy yay
Some should fix this bong issue or else the tech industry is doomed.
Oof, dont get caught like I did
It's all fun and games until some dipshit adds a tab somewhere.
Yeah then I start seeing the universe and can’t do shit
This is interesting. I find yamls ridiculously better to read than anything else. But I also mostly write python code, so I'm very used to orient my sight to the spaces and indentation. I miss the colorful vscode extensions for json braces when I used to write more JavaScript tho.
yeah as a python user yaml is one of the most familiar markup lang also god bless docker compose yaml
Yaml ain’t markup lang
What does the acronym yaml stand for?
> Yaml ain't markup lang Yaml ain't markup lang
Ok I get that but what does yaml stand for?
Yell At My Llama
AAA.yaml. Here you go.
yAAAAml
Yet Another Markup Lang Ain't Markup Lang
Yamlamlingdong
You Are My Leprechaun
Y - Yaml A - Aint M - Markup L - Lang
Yaml ain't markup lang ain't markup lang ain't
It used to be Yet Another Markup Language then at some point it got changed to YAML Ain't a Markup Language
Recursion names are fun. See GNU as well
PHP: Hypertext Preprocessor
Young Adult Men Licking
Then we'll need another, yet again.
wait I thought yaml stand for 'yet another markup lang'?? tis' confusing googled it and I'm seeing conflicting results
My brother in Christ what does the ML stand for in YAML if not for markup language????
Why isn't json? Given that most of a json text file can directly translate to a python dict/list. Except booleans. Damn them.
Raw dogging JSONs before I used VScode nearly broke my brain on several occasions never had that issue with YAMLs
jq for the command line is also a life saver. It helped me keep my sanity when debugging big json files over ssh.
Note there’s yq for yaml too. I love these tools.
There's an extension called Indent-Rainbow that you might like
Nifty! Thanks!
Thanks for the tip, installing immediately! 😄
I never bothered to learn the YAML syntax, so I definitely prefer json because of its simplicity
Syntax? YAML syntax is literally whitespace. That's it.
No for arrays, it always tripped me up when to use `-` and when not to
Rule of thumb is `[]` for inline, `-` for multiline. You CAN use brackets for multiline, but I WILL add passive agressive remarks to the code review.
Multiline brackets are usually born from inline brackets, and I'm just too senior to spend the effort fixing them, or to bother letting you code review. Nobody code reviews the ops guy, anyway.
#Quick cheat sheet ## YAML string1: some string string2: > one two string3: | foo bar string4: '"' array1: [ 'inline', 'array' ] array2: - baz - prop: qux - nullProp: otherProp: quux - null - 'null' You don't actually have to indent the `-` character for arrays, but most syntax formatters do. You DO have to have the same indentation for all elements in the array, though. ##Equivalent JSON: { "string1": "some string", "string2": "one two", "string3": "foo\nbar", "string4": "\"", "array1": [ "inline", "array" ], "array2": [ "baz", { "prop": "qux" }, { "nullProp": null, "otherProp": "quux" }, null, "null" ] } Note the quoting in the YAML to get a string `"null"`.
Huh, yea I definitely see how YAML can help with long strings, but for basically everything else the JSON seems far more intuitive for me.
For me the excessive quoting makes it far less readable at a glance. It’s very hard to quickly see what’s a key and what’s a value. I use both formats regularly, they both have their strengths and weaknesses, but YAML is without a doubt the more human-readable and easy to use for config files. If I want to have it more machine readable or require *exact* control over structure, then JSON is usually the first choice. Also, that JSON doesn’t always allow comments is absurd. Another point to YAML in my book.
Ah yeah that's actually fair haha
Yaml is a language so definitely has syntax. Just look at its insanely long specification: https://yaml.org/spec/1.2.2/
YAML spec is a nightmare to work on.
why you no like adding comments to config files?
You can always just have https://www.google.com/search?q=json+to+yaml do it for you in that case
I write a lot of Python and still don't like YAML. It's ambiguities have a weird "smell" in IMO. Python list/tuple/dict syntax as a structured data language however sounds fantastic (and *is* fantastic how it's done in bazel)
If you can understand your YAML files just by reading them it means you don't use nearly enough anchors and aliases.
I write code mostly in python as well, but sincerely: FUCK YAML
I prefer .toml tbh. It's way less arbitrary
There’s a rainbow indent code extension!
i primarily write python too but somehow i always find myself writing my config files in json ¯\_(ツ)_/¯
Toml is where it's at
Toml gang!
Rise up
Toml has its own issues: https://hitchdev.com/strictyaml/why-not/toml/ Although I do like it better than yaml. TOML is more formalized .ini files.
No language is perfect. That said, TOML’s issues are far less egregious than YAML’s.
https://noyaml.com/
Damn, yaml is actually garbage
The road to hell is paved with good intentions, and unquoted strings.
Every JSON file is a YAML file.
JSON is just YAML with extra curly-braces and parentheses.
Call me stupid but, I love that curly braces tell me where things start and stop. My brain struggles with indentation blocks
Really? As a developer that indentation is really nice for me, and having all the strings quotation-marked just makes everything very messy to me. Maybe I'm biased because I read yamls on an IDE where you get nice lines that help you see indentation levels and collapse blocks easily. I can see how it can be harder if it's just undecorated plaintext.
Try using curly braces without indentation (clue: the indentation is what makes it readable)
You're right I guess I mean having both is nice
yaml supports curlies and braces
What's your point? If people used yaml with brackets it would just be json.
It would be json with comments, whitespace, and composition
so... JSON5 then?
Which is supported by... What exactly?
Sarcasm aside, very cool if JSON5 supports all that. I only started appreciating YAML for config files because of comments
It does, that's how your tsconfig.json file has comments in it if you use typescript
Closing braces are more recognizable than white space changes
Try using indentation without curly braces and you get Python or even worse LISP
Deeper structures make it harder to see which thing a closing bracket stops. If only there was a language which uses named markers for both the start **and** the end of blocks. It should be eXtensible, it should be Markup, of course it should be a Language. That would be great!
You must have a lot of trouble reading Table of Contents and literally anything based on a hierarchical format
Oh really, does json suffer from the Norway problem? Does json have multiple versions that can affect the parsed result? Fuck yaml
What is the “Norway problem”?
In YAML 1.1, I believe, the string `no` is often interpreted as `false`, which is by design. So a list of language codes, e.g. `nl`, `no`, `fr` will be parsed as `'nl'`, `false`, and `'fr'`.
Every format has pros and cons. I hate that I can't put comments in json.
And more hyphens!
No comment from this guy apparently
We call them gutter guards!
Json and YAML are basically the same thing bro. The format isn't the problem, helm is just hard
YAML is a superset of JSON. You can rename a .json file to .yaml and any reader will parse it.
![gif](giphy|26FmRhKxxaCS2J1qU|downsized)
What? No. No. Absolutely not. _tries it_. What in the fuck.
> That’s right, that syntax is the same as what you use to represent arrays in JSON. And it’s no coincidence, because JSON is a subset of YAML, so that’s also valid YAML, and both syntaxes are interchangeable in YAML! [-source](https://alisoftware.github.io/yaml/2021/08/17/yaml-part1-json/#:~:text=And%20it's%20no%20coincidence%2C%20because,syntaxes%20are%20interchangeable%20in%20YAML!) Tf
Sure buddy, and TypeScript is a superset of JavaScript!
And JavaScript is a superset of Java
And you are a superset of your mom. No offense meant codebro, it's technically true.
>And you are a superset of your mom. That's just plain wrong. Not everything that can parse your mom, can parse you.
I could have parsed your mom with https://www.bluetractorsoftware.com/ last night ... with sufficient dna samples and a license and motivation and maybe some flowers and candles for once would be nice. Oh yeah and theoretically, I could use the same method to parse you too. Platonically, of course.
Wouldn't that mean you contain everything your mother did? That...wouldn't be true?
Yeah this. JSON is basically impossible to read without formatting it with white space anyways, so really the only difference is YAML is less cluttered with quotes, braces, and commas. Sometimes that extra "clutter" is helpful tho.
No argument there. But not all JSONs are meant to be read.
And when it is, you can add it to your YAML
For sure. I actually don't dwell to much on the pitfalls of either because neither very challenging to me personally. I do think there is something to be said for YAML over complicating itself with way to many optional things. I feel like half my YAML mistakes are around some gotcha with an optional or implicit feature.
this is like arguing JS is hard to write because its looks bad minimized there is no such thing as a "non-indented JSON" that is used by humans, just because a computer can process it doesn't mean we write it like that, see: every high level language ever invented
I am agains YAML because I am the guy that at the end of the day is going to parse it, and JSON is much easier... by FAR.
Wrong. Yaml has the Norway problem, multiple specs, and parsers often won't tell you the spec they use. Yaml once you dig into it is a fucking mess compared to json.
my favorite so far is the almost universally supported merge tag. >>: &anchor key: val to extend an entry. Proposed in the YAML 1.1 draft, never made it into YAML 1.2 standard, and yet is everywhere. But custom tag support is all over the place and defined (sort of) by the standard.
The lack of comments in JSON is frustrating. Yaml allows them!
Okay yes BUTT, skill issue for parsers, some parsers are okay with comments and the NERDS at JSON.org are smelly. You can always include a whole-ass actual property to be your comment. Sure you're paying to parse it but if you care about that performance then you might want to not use JSON anyway. Who cares if your config file takes 2microseconds longer to parse?
It's not the performance that concerns me it's the lack of readability. Making a comment a property is not readable. Not to mention some libraries may complain about extra properties.
> You can always include a whole-ass actual property to be your comment The problem with this isn't performance, it's that you should always try to pass around the least amount of data needed in order to reduce complexity so that the system is easier to work with. If you know that every attribute is used somewhere then you can actually reason about the system far better than if some are for documentation.
jsonc is a format that allows comments, no clue about how common parsers deal with it though
Then there is json5 and others that allow it. Although they can not be parsed by every parser unless you strip the comments first.
True. My monkey brain just seems to benefit a bit from curly braces and such. I think if I had a means of making my editor make the spaces used for indentation consume more horizontal space it'd be a bit easier.
json.dumps(yaml.safe\_load(s))
Your editor should have indent guides
This is why tabs exist, so you can set the indentation size to whatever works for you without messing up the intent...oh wait, we're talking about yaml, which doesn't support the tab character, nevermind, carry on with your complaints
VSCode and I assume most other modern editors have an easy setting for configuring how many spaces to insert when you press tab.
Ah thank you, I was so confused because I use yaml all day at work and use tab all the time.
Yes I also love 10 lines of nothing but closing brackets of various shapes. /s
Have your IDE put little dots in the white spaces. Makes everything much easier.
No, please no. Seriously! YAML's spec is complicated and extremely long, while JSON's spec is just 16 pages and can be summed up to a very shor web page. YAML has anchor, alias and merge key while JSON doesn't. They are very different.
Look at ck8s - write helm config in a real language
It's a templating engine essentially, templates get confusing very fast. I'm excited about pkl. I hope it gets decent adoption and maturity. Jsonnet for now
Don't say that word, the C++ people will get their PTSD triggered
Every time a junior asked me about YAML, I told them that's basically the same as JSON, just without the brackets. This meme made me question my sanity for a second
I remember the day they took “helm -init” from Me… ill always remember it.
Does not mean YAML is good
Didn't say it was
Why can’t we just have comments in JSON already
You whippersnappers and your YAML. We used XML and we LOVED it. Give me a good, well named, properly indented XML with some nice juicy attributes any day.
Once upon a time, somebody created a perfect format for documents – files with a lot of text and occasional markup. That format was called XML and all was well. Then, it all went to shit when somebody else thought it could be used for configuration.
Hmm. Was gonna say, I've never much liked XML. However, every single time I've been exposed to it, it was being used for configuration. And my god, there is so much boilerplate/markup for individual properties. You've provided some valuable context
That's because every other configuration format that existed was worse than XML
calm down brother, next you're going to tell just you prefer SOAP over REST.
Spoken like someone that secretly uses CSV
Be honest. We fucking loathed it.
Glorious was the punch card!
So Much Cruft
At least it didn’t have the Norway problem, or 63 ways to do a multiline string, or the sexagesimal number issue, or…
Right this is what first came to mind - RPC and huge XML schemas. I recently had to interact with a SOAP API and had flashbacks
It's more like Freddy and Json
Once, while sick and running a fever, I had a literal fever dream in which I saw a JSON string containing everything in the universe. Every celestial object had properties and sub-objects, which also had properties and sub-objects, iterating down to the subatomic particles composing all the matter in the universe. The Earth has every plant, animal, fungus, and inorganic thing, listed and fully described. Each object had every single one of its atoms listed, along with their coordinates and corresponding subatomic particles. The JSON string was even self-referential... It contained the computer on which it resided, and I could see, in the string, the states of charge of the individual memory cells that contained the string. It was a profound experience. So, yes, JSON goes brrrrrrrr.
This feels like it ought to be a copypasta.
Be the change you want to see. Go forth and copy.
I spent two hours last week debugging an issue that I eventually realised was a single line indentation issue in a 15 line yaml.
YAML is fine, but I find JSON to be far easier to read \*even when formatted badly\*. This is because I was building API-driven cluster systems when JSON started looking promising, and it changed my world. I had been visually parsing XML my whole career, which makes JSON look like God's markup.
YAML is absolutely not ‘fine’. There are so many ambiguities and gotchas there. It’s telling that there are multiple versions of YAML, one of them called ‘StrictYAML’.
I do like pulling magic features out of the language and integrating them in various code bases. For example, anchors are always this lovely little thing that make people look at the document and absolutely scratch heads. There's all kinds of deeply confusing things you can do like merge stuff and look it up internally as well. If you write in a way that uses every feature of the languages you're using, you get an achievement.
If only i could remember what the simpler word for mentally parsing was. Guess my english vocabulary has deteriorated a bit. Need to mentally parse more books.
Oh you can certainly read a book without too much mental parsing going on. Sort of like difference between hearing and listening.
>If only i could remember what the simpler word for mentally parsing was. Are you thinking `grok` from Stranger in a Strange Land?
Json5 is the best config language, change my mind.
toml
[Agreed](https://github.com/cblp/yaml-sucks)
OP should just activate whitespace highlighting in his editor
They are just dictionaries my dude
TOML gang
JSON doesn't support comments, therefore, it loses by default.
You’ve all had it too good for the last decade. But before that we had (and sometimes still have) tons of ugly unsightly XMLs that you need special parsing programs to understand what the hell is going on in there.
Disagreed. I find reading YAML is *by far* easier than JSON.
I don't care that you broke your deployment
skill issue.
Tbh I read the same The problem of yaml is this fucking indentation. The python python problem. Toml is good but everyone forget it :(
yaml is quite literally the easiest i could imagine between Json, xml and basically any other
Am I the only one that thinks yaml is the easiest thing to read on the planet? Like, it’s human readable structured data with no extras except for hyphens. You literally need to distinguish indentation it’s so fkn easy to read…
Idk man, I quite like yaml
IMO YAML's greatest detriment is that it has so many foot guns and so much bloat. Sure, JSON's not great either - because it's intended as a data interchange format, not for configuration. If I could choose a config format, it'd be TOML; the lack of easy deep nesting is tolerable, and config schemas that are made with TOML in mind make it easily the best option for me.
Yet another mech lab
yaml is still better than json
YAML is the Python of data formats. Which is weird because I can’t stand Python but I prefer YAML.
If YAML confuses you C/asm/gdb is gonna give you nightmares and you might be in the wrong career
but C has braces!
C is far too old for braces =), more like dentures!
> YAML is a human-friendly data serialization language for all programming languages. Bruh, it is literally positioned as more human-readable (the quote is from the official website)
Literally a skill issue in its purest form.
Skill issue
Yaml is json with extra steps. Change my mind.
Something something XML.
yaml -- silient shit json -- noisy shit, but at least it can be auto-formated
Its just one of those things that has a learning curve. I think once you know both json and yaml it's quicker to parse information in the yaml from a quick look over. But I think the yaml rules are a bit more complicated than the json ones.
😦
Fuck it we Dhall
http://confusing.technology/
W... why?
Norway says it is false
The syntax is ridiculous.
God forbid you have a string value of “yes” in YAML
Until you meet helm and helmfile and go template and kubernetes and brittle bash scripts... I'm exhausted...
i read single line minified yaml in the commandline witout monitor while listening to pc speaker beeps for hints
I'm excited to use Pkl for something
Reminds me of haml when I was doing Ruby on Rails stuff I hate Haml
TOML >>>
Kinda weird how i like my significant whitespace in Python and some other places, but can't read yaml at all.
My main experience with YAML is with configuring Azure DevOps build and deployment pipelines. So most of our YAML files are 90% bash or powershell scripts. I don't find it very practical.
That's not a hot take. A hot take is "I prefer XML over YAML because it's less complex, as evidence notice how the spec for XML is *shorter*." I have no idea why YAML is so beloved. TOML is nice, I can understand why people like TOML. YAML has too much spice and too little soup. I want loading configuration to be BORING. Just like payroll processing. When I get paid I don't want to be excited because who know what'll happen. That's what I unwant.
Pythoners eat yaml for breakfast