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

81–90 of 144 posts

Re: YAML document from hell (2023)

#81

Post by al_borland »

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 found job slicing speeds up jobs dramatically. In a test I did recently it dropped the time from nearly 4 hours, down to 17 minutes, for an inventory of about 4500 hosts.

Re: YAML document from hell (2023)

#83

Post by darkwater »

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…

I see where you are coming from but YAML anchors are definitely a great and powerful feature that deserves more attention. The other day I was refactoring a broken [1] k8s deployment based on a 3rd-party Helm chart and since I didn't have the time to migrate to a better chart, YAML anchors permitted me to easily reduce YAML duplication, with everything else (Helm, Kustomize, Flux, Kubernetes) completely unaware of anything. Just a standard YAML pattern.

[1] the broken part was due to an ex-coworker that cheated his way out of GitOps and left basically "fake code" committed, and modified by hand (with Lens) the deployment to make it work

Re: YAML document from hell (2023)

#84

Post by speed_spread »

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.

The article mentions

> A simple subset of yaml

Which already exists and is called StrictYAML. It's just strings, lists and dicts. No numbers. No booleans. No _countries_. No anchors. No JSON-compatible blocks. So, essentially it's what most of use think as being proper YAML, without all the stupid/bad/overcomplicated stuff. Just bring your own schema and types where required.

https://hitchdev.com/strictyaml/

Re: YAML document from hell (2023)

#85

Post by speed_spread »

Ajedi32 wrote: post #75
bmacho wrote: post #38

Earlier quoted context omitted.

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

For configuration I dislike the XML object model KDL is built around. It needlessly complicates things to have two different incompatible ways (properties and children) of nesting configuration keys under an element. Pkl seems syntactically beautiful and powerful, but having types and functions and loops makes it a lot more complicated than the dead-simple JSON data model that YAML is based on.

In JSON I often end up recreating XML attributes equivalent for metadata fields and using custom prefixes to differentiate those fields from actual data. I find it's nice the data/metadata separation at the language level.

Re: YAML document from hell (2023)

#87

Post by rendaw »

munificent wrote: post #58
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…

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

JSONC is JSON with comments (and trailing commas) and it's fairly widely supported, namely because VS Code ships with support built in and they use it for all their config files. I've seen libraries for a number of languages.

VS code defaults to complaining about trailing commas though (the warnings can be turned off though (it feels like a hack and they didn't properly document it though (it is an officially sanctioned procedure though))).

Re: YAML document from hell (2023)

#88

Post by Ajedi32 »

speed_spread wrote: post #85
Ajedi32 wrote: post #75

Earlier quoted context omitted.

For configuration I dislike the XML object model KDL is built around. It needlessly complicates things to have two different incompatible ways (properties and children) of nesting configuration keys under an element. Pkl seems syntactically beautiful and powerful, but having types and functions and loops makes it a lot more complicated than the dead-simple JSON data model that YAML is based on.

In JSON I often end up recreating XML attributes equivalent for metadata fields and using custom prefixes to differentiate those fields from actual data. I find it's nice the data/metadata separation at the language level.

Can you give an example of metadata you would put in a config file that isn't configuration and isn't a comment?

Re: YAML document from hell (2023)

#90

Post by Diti »

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?

Most protocols defined in RFCs require the use of regular JSON. You don’t have a choice.
Post reply on HN