YAML document from hell (2023) • Hacker News Board

Re: YAML document from hell (2023)

#31

Post by phito » Tue, Sep 23, 2025, 12:47 PM UTC

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.

how is it annoying...? it's literally like that in almost every single language out there. IMO seeing unquoted strings in YAML feels weird.

Re: YAML document from hell (2023)

#32

Post by seiferteric » Tue, Sep 23, 2025, 12:52 PM UTC

I wonder if you could make a new standard something based on yaml where every value was prefixed by a type so there is no ambiguity.

Re: YAML document from hell (2023)

#33

Post by mcdonje » Tue, Sep 23, 2025, 12:52 PM UTC

aranw wrote: post #22

I find it remarkable that YAML has become our goto for configuration when it is riddled with parsing traps and inconsistent behaviour that catches out even experienced developers

It's because other config formats aren't as expressive.

Re: YAML document from hell (2023)

#34

Post by loudmax » Tue, Sep 23, 2025, 12:53 PM UTC

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.

Re: YAML document from hell (2023)

#35

Post by baobrien » Tue, Sep 23, 2025, 12:56 PM UTC

raincole wrote: post #6

The n, no, off thing is just sad. It's a 100% avoidable issue. But whoever put that into spec was just so clever that they overflew and became stupid.

Too clever by half

Re: YAML document from hell (2023)

#36

Post by lazystone » Tue, Sep 23, 2025, 12:56 PM UTC

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...

Re: YAML document from hell (2023)

#37

Post by mystifyingpoi » Tue, Sep 23, 2025, 1:04 PM UTC

phito wrote: post #31

mystifyingpoi wrote: post #24

Earlier quoted context omitted.

> 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.

how is it annoying...? it's literally like that in almost every single language out there. IMO seeing unquoted strings in YAML feels weird.

As I said, it's subjective. I like this

    image: my-repo.com/my-app:v1
    imagePullPolicy: Always

more than this

    image: "my-repo.com/my-app:v1"
    imagePullPolicy: "Always"

That's all. Not sure about quoting keys though.

Re: YAML document from hell (2023)

#38

Post by bmacho » Tue, Sep 23, 2025, 1:10 PM UTC

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.

What about KDL (https://kdl.dev/) or Pkl (https://pkl-lang.org/)?

Re: YAML document from hell (2023)

#39

Post by Titan2189 » Tue, Sep 23, 2025, 1:10 PM UTC

seiferteric wrote: post #32

I wonder if you could make a new standard something based on yaml where every value was prefixed by a type so there is no ambiguity.

Obligatory https://xkcd.com/927/

Re: YAML document from hell (2023)

#40

Post by ruuda » Tue, Sep 23, 2025, 1:11 PM UTC

endgame wrote: post #15

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.

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?