Author of the website here. Send this in as a pull-request please.

Damn! I’m guessing most developers today wouldn’t even know octal or how octal numeric literals are written with a “0” prefix. I actually laughed when I read this comment, but this behavior (and assumption) is ridiculous considering the fact that almost nobody would be using octal in some configuration file in 2023. Hexadecimal? Maybe. Decimal? Yes. Octal? C’mon!

Actually I'd like to use octal. 0777 for example.

But fuck this particular type conversion semantic.

Which - seeing like that, were the Linux file permissions originally octal? When thinking about permissions and permutations... and old magic numbers, that seems like the bits might fit.

Well they were grouped in blocks of 3 bits so octal is a good representational format for 3 bits.

Just switch to ugo / +- / rwx, much more intuitive.

Octal is very commonly used in Ansible playbooks, for representing file permissions

Exactly there I was hit so many times by not using quotes around file permissions, because 0644 is interpreted as 420 and Ansible sets the permissions to '-r---w----' instead of '-rw-r--r--'.

Here's a relevant suggestion from the Ansible docs (https://docs.ansible.com/ansible/latest/collections/ansible/...):

For those used to /usr/bin/chmod remember that modes are actually octal numbers. You must give Ansible enough information to parse them correctly. For consistent results, quote octal numbers (for example, '644' or '1777') so Ansible receives a string and can do its own conversion from string into number. Adding a leading zero (for example, 0755) works sometimes, but can fail in loops and some other circumstances.

Despite this, I still think YAML is a nice configuration language. The problem is not with YAML, it's with the whole complexity we're trying to represent there. Whatever configuration language you use, the outcome will be the same. Reduce the complexity, and it will shine.

Oh my god I think you solved a work problem I was recently having

> resulted in a complete k8s cluster failure for us, but only the 08 cluster! It worked in the first 7.

This actually made me LOL, that's amazing

Really?? How can this possibly be right?

YAML parses the value as a number if possible.

07 is the octal number 7.

08 is not a number.

Missing piece: And in some languages, a number with a leading zero is interpreted as octal.

Could be more specific about what part of the 60+ page YAML spec you have in mind?

https://yaml.org/spec/1.2.2

> Whatever generated that clearly wasn't serializing its data using a library

Wow, you couldn't ask for a stronger condemnation than that for YAML as a configuration language. "You clearly weren't using a library to write your config file".

In the world I live in, config file formats exist to be written and read by humans. Serialization formats exist to be generated by libraries.

Not to mention YAML itself purports to be human friendly. Otherwise the config files would have been JSON or something else.

There's always an assumption that if you do things perfect you'll never run into issues.

But it's not unreasonable to expect 07 and 08 to work consistently.

It was somewhere in the middle of a helm chart we imported. So we're building on the shoulders of stuff no one knows how to use.

Yeah, helm is...interesting. it's just a gnarly yaml -> template -> yaml cycle. it's better than nothing for the problem it solves....but god, there's gotta be a better way.

Just use JSON for everything that is supposed to accept YAML, and rely on the fact that the entirety of JSON is somehow a subset of YAML and that most YAML never actually needs the "features" of YAML.

At least with JSON, tooling can help you find invalid syntax in the middle of your file.

And JSON tooling/libraries (compared to YAML tooling/libraries) are usually faster, easier to use, have less bugs and present less incompatibilities between themselves most of the time.