There’s a made-in-golang alternative here that I haven’t looked into.

(Maybe “alternative” isn’t the right word in case it came first, I dunno, but I’ve been happy enough with the Python one.)

The relationship between YAML and JSON makes me hate both less.

(Or I guess hate JSON less and love YAML more since YAML was already leaning positive after coming through a rocky patch of kinda hating it.)

Yeah, yeah, it’s always gonna baffle me how we threw away schema’d outlines of elements & attributes for an un-schema’d hodge-podge of sequences and maps. I like XML (not the angle-bracket notation for it) more than JSON and probably always will.

Convert OpenAPI/Swagger specifications into clean, self-contained JSON format with resolved references. Support for OpenAPI 2.0, 3.0, and 3.1.

I can breathe a sigh of relief since my YAML-writing environment (Emacs with a flycheck to yamllint and a keyboard combo to view a sexp representation of the region or document) caught all the errors except for reading 10.23 and 12.13 as numbers, which… they are numbers. jq also kvetchlessly accepts them as numbers, but it borks on unquoted 9.6.24 so in this particular case, since there happened to be some tripart numbers, jq would’ve detected the issue.

Conclusion: I don’t need to worry and can keep on YAMLing.

None of that is take away from Ruud’s two main points:

Select, put and delete data from JSON, TOML, YAML, XML and CSV files with a single tool. Supports conversion between formats and can be used as a Go package. - TomWright/dasel

Simple, lightweight, extensible, configuration management library for Go. Support for JSON, TOML, YAML, env, command line, file, S3 etc. Alternative to viper. - knadh/koanf: Simple, lightweight, extensible, configuration management library for Go. Support for JSON, TOML, YAML, env, command line, file, S3 etc. Alternative to viper.

On why YAML is a terrible format.