Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

YAML document from hell (2023)

ruudvanasseldonk.com

Post reply on HN
Print view View original

101–110 of 144 posts

Re: YAML document from hell (2023)

#101

Post by sunrunner »

com2kid wrote: post #93
lucideer wrote: post #53

Earlier quoted context omitted.

I feel like these two tenets - (1) yaml should require quotes & (2) the value in yaml is in recursion/anchors - are fundamentally the opposite of why yaml exists & why people use it. The distinguishing draw of yaml is largely the "easiness" of not having explicit opening or - more importantly - closing delimeters. This is done using a combination of white-space delimiting for structure, & heuristic parsing for values…

Genuinely curious - What major flaws does TOML have? I've used it before and it seems like a simple no-nonsense config language. Plenty of blog articles about the flaws behind YAML, I don't really see complaints about TOML!

> I don't really see complaints about TOML!

Sampling bias, there are no complaints about it because no-one uses it (jk).

It's subjective of course but despite the name TOML never really seemed that 'Obvious' to me, in particular the spec for tables. I also think the leniency in the syntax isn't necessarily a good feature and serves to make it less 'Minimal' than its name suggests.

Re: YAML document from hell (2023)

#102

Post by munificent »

lucideer wrote: post #77
munificent wrote: post #58

Earlier quoted context omitted.

> The distinguishing draw of yaml is largely the "easiness" of not having explicit opening or - more importantly - closing delimeters. Along with a coworker, I wrote the package manager for Dart, which uses YAML for its main manifest file (pubspec.yaml). The lack of delimiters is kind of nice but wasn't instrumental in the choice to use YAML. It's because JSON doesn't have comments. If there was a JSON+comments what…

> It's because JSON doesn't have comments. This is a big plus but JSON5 has pretty widespread language library support - probably equal to that of YAML tbh (e.g. Swift has native JSON5 support, I don't know that anyone natively supports YAML). Any reason not to opt for it here?

I believe JSON5 didn't exist when we first wrote pub. If it did, it certainly wasn't widely known.

Obviously, migrating to it now when there are thousands and thousands of packages and dozens of tools all reading pubspecs would be much more trouble than it's worth.

Re: YAML document from hell (2023)

#104

Post by feoren »

loudmax wrote: post #34
h1fra wrote: post #11

not only is YAML a pain but JSON has native parser in major languages, while not yaml. I find it crazy some people are still actively choosing this over JSON (or alternatives)

This is a case of the right tool for the right job. YAML is far easier to read and parse as a human than JSON. If you're passing data between processes, and you still want the data to be human readable, then JSON is a good choice. If you're writing a configuration file that's going to be edited by a human, then YAML is easier to look at and understand.

> YAML is far easier to read and parse as a human than JSON.

When you're on line 4000 of a YAML configuration file and the previous 70 lines have been at indentation level 6, and you see a blank line and another line at indentation level 4 (or is that 5? maybe 3?) then I strongly, strongly disagree that two '}' characters are more difficult to read than newlines, tabs, and spaces.

YAML is one of a family of languages borne from the idea that punctuation is bad and therefore should be invisible. Not gone, because all of these languages still have punctuation. No, these characters that are critically important to the interpretation of the file must be invisible.

Code and markup is easy to read when it is easy to predict what the computer will do when it parses it. Invisible punctuation makes the files harder to read, not easier. The only thing easier in YAML is writing it in the first place, and we all know that "write-only" is an insult.

Re: YAML document from hell (2023)

#105

Post by mrgaro »

lazystone wrote: post #36
Kostarrr wrote: post #13

So... what are the good alternatives to yaml? For quite some time I thought toml, but the way you can spread e.g. lists all over the document can also cause some headaches. Dhall is exactly my kind of type fest but you can hit a hard brick wall because the type system is not as strong as you think.

No one mentioned HashiCorp HCL so far, though it's really a shame that it didn't get much traction...

HCL is so annoying as it tries so much to prevent user to "do too complex things" and thus it doesn't have proper iterators other similar concepts, which would be very useful when defining infrastructure as xode.

This has resulted bunch of hacks (such as the count directive on terraform) so that the end result is a frustrating mess.

Re: YAML document from hell (2023)

#106

Post by onraglanroad »

TheTaytay wrote: post #76
dreamcompiler wrote: post #67

Earlier quoted context omitted.

Seems like the right answer is "bootstrap your daemon installs with Ansible and then use something that scales better that runs on those daemons." What are the best practices along these lines? What's the "something better"?

Curious about this myself!

I tend to use Ansible to set up for Puppet.

There's an Ansible provider for Terraform so you can do the whole thing in there.

Re: YAML document from hell (2023)

#107

Post by apexalpha »

Up until now I thought YAMl was just json with all the special characters like { } replace by \n and stuff to make it human readable.

I had no idea it was even so opinionated.

Mostly I use it for docker and k8s configuration, so I haven’t run into it yet I suppose

Re: YAML document from hell (2023)

#108

Post by lambdaone »

What's needed is something that is simple for humans to read and write, has a stable definition, and a clear and unambiguous syntax and mapping to data objects.

None of the systems I've seen achieve all those goals at once.

YAML, while at first sight a good idea, is irredeemably broken and should be deprecated for further use.

JSONC (https://jsonc.org/) is backwards-compatible with JSON, and a good target for long-term future migration.

.INI format works well as a structured subject-predicate-object tuple store for simple use cases.

We're probably going to have to live with that indifinitely, until someone comes up with a proposal that is better.

Re: YAML document from hell (2023)

#109

Post by RedShift1 »

BobbyTables2 wrote: post #4

I’m amazed how sane the “document from hell” looks. The author didn’t even get into the weird stuff GitLab does with YAML too!

Not gonna lie, I use Google and copy paste the stanzas that do the thing I want it to do. Same for Maven, someone somewhere has already solved the same problem I have, all I need to do is copy paste and adjust to my situation.

Re: YAML document from hell (2023)

#110

Post by gu009 »

lambdaone wrote: post #108

What's needed is something that is simple for humans to read and write, has a stable definition, and a clear and unambiguous syntax and mapping to data objects. None of the systems I've seen achieve all those goals at once. YAML, while at first sight a good idea, is irredeemably broken and should be deprecated for further use. JSONC ( https://jsonc.org/ ) is backwards-compatible with JSON, and a good target for long-…

Tailscale also have HuJSON: https://github.com/tailscale/hujson
Post reply on HN