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

91–100 of 144 posts

Re: YAML document from hell (2023)

#91

Post by lillesvin »

montroser wrote: post #60
lillesvin wrote: post #18

Earlier quoted context omitted.

> Almost all of this is solved by basically putting quotes around strings. Yeah, that was my first thought as well. I personally don't mind YAML, but I've also made a habit out of quoting strings. And, I mean, you're quoting both keys and strings in JSON, so you're still saving approx. 2 double quotes per key/value pair in YAML if that's a metric that's important to you.

As the article points out with the `on` example, you really have to quote yaml keys as well, if you want the defense to work...

The argument was that most of the mentioned problems could be solved by quoting the values. I don't have a problem with avoiding "on" as a key, and I apparently haven't used it ever, because I've never run into this particular problem in my 15+ years using YAML.

So, sure, if you want to play it super safe, quote keys as well. But I'm personally fine with the trade-off in not quoting keys.

Re: YAML document from hell (2023)

#92

Post by privatelypublic »

Someone wrote: post #48
privatelypublic wrote: post #46

Can't take this seriously if XML isn't listed as an alternative.

FTA: Xml is noisy and annoying to write by hand

So, at what point does YAML needing magic incantations, wrapping everything in quotes, avoiding any form of templating, etc. stop being less verbose (oops, meant noisy), and "annoying?"

Reality is, clunky XML is badly designed, or simply has no schema attached.

Re: YAML document from hell (2023)

#93

Post by com2kid »

lucideer wrote: post #53
twelvechairs wrote: post #5

Almost all of this is solved by basically putting quotes around strings. Yaml has its uses cases where you want things json doesnt do like recursion or anchors/aliases/tags. Or at least it has had - perhaps cue/dhall/hcl solves things better. Jsonnet is another. I havent tried enough to test how much better they are.

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!

Re: YAML document from hell (2023)

#94

Post by rswail »

ruuda wrote: post #40
endgame wrote: post #15

Earlier quoted context omitted.

I wish I had a good answer for you. I've been dissatisfied with Dhall, Nickle, Cue, and possibly others. Dhall's type system is both too strong (you have to plumb type variables by hand if you want to do any kind of routine FP idioms) and too weak (you can't really _do_ much with record types - it's really hard to swizzle and rearrange deeply nested records). On top of that, the grammar is quite difficult to parse. Y…

> Maybe Nix in pure eval mode, absurd as that sounds? It doesn’t sound absurd, it’s pretty nice. What do you think about https://rcl-lang.org ?

Just been reading the docs, I like it :)

Gonna have to set aside some time to play with it compared to HCL where I spend a lot of time.

Re: YAML document from hell (2023)

#95

Post by rswail »

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 ok except for the lack of user defined functions which leads to clumsy tricks with nested comprehensions.

Given its general use around infrastructure, it'd be nice if it had IPv4 and IPv6 addresses as native types that get parsed.

Re: YAML document from hell (2023)

#97

Post by unconed »

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!

TOML is basically a formalization of the old INI format, which only existed in ad-hoc implementations. It's not really a "language", just a config data syntax like JSON. It doesn't have major footguns because it doesn't have a lot of surface area.

The various features it has for nesting and arrays make it convenient to write, but can make it harder to read. There is no canonical serialization of a TOML document, as far as I can tell, you could do it any number of ways.

So while TOML has its use for small config files you edit by hand, it doesn't really make sense for interchange, and it doesn't see much use outside of Rust afaik.

Re: YAML document from hell (2023)

#99

Post by gchamonlive »

sofixa wrote: post #64
gchamonlive wrote: post #21

Earlier quoted context omitted.

Ansible isn't a gold standard for docs. The docs are updated and maintained, but the underlying interfaces aren't consistent and that leaks to the docs. One can only wonder why, maybe different developers with different ideas for conventions without a style guide. Ansible is a wonderful tool though, if you can excuse these idiosyncrasies.

> Ansible is a wonderful tool though, if you can excuse these idiosyncrasies. The only advantage Ansible has is how easy it is to start with it - you don't need to deploy agents or even understand a lot about how it works. Trouble is, it doesn't really scale. It's pretty slow when running against a bunch of machines, and large configurations get unwieldily quickly (be it because of YAML when in large documents its im…

I've had the opposite experience. A bit hard to setup, with ssh-agent, inventories and understanding what each module does, and creating specialized roles. So for quick jobs, plain bash with ssh wins most of the time.

But once ansible is set, it's easy to achieve parallelism when provisioning multiple instances.

Problem is that it requires lots of back and forth over ssh, so the more latency you have between the control plane and the target hosts the slower it'll be.

And yeah... Debugging is a pain. I wish I could write ansible in an actual language instead of having to fight multiple layers of indirection with ansible, jinja2 and yaml.

Re: YAML document from hell (2023)

#100

Post by vivzkestrel »

mystifyingpoi wrote: post #24
vivzkestrel wrote: post #17

stupid question: why dont they announce a newer version of YAML that is not backwards compatible and allow only quoted strings in their parser?

> that is not backwards compatible This would be a massive breaking change for Kubernetes. There are piles and piles of YAML all around the opensource that would need updating. It would be very hard to adopt. Also, quoting strings 100% of the time just looks ugly in my opinion. Not a big deal with autogenerated YAML, or YAML that I do not maintain, but for anything handwritten it's annoying.

is it a massive change? yes, will it cause serious problems for existing apps in production? yes. but think of this as one of those python 2 to 3 moments. They could improve the spec dramatically and cut the parser down by a crazy amount to detect edge cases. It ll be a bright direction forward for YAML
Post reply on HN