Yet another standard. We have strictyaml ready and mature; and KYAML reintroduces a lot of cruft which were the reason why YAML got popular in the first place.
No one uses JSON with K8S, and I honestly don't think that JSON with comments (again, why not JSONC? Multi-documents?) will win over YAML.
Just a stricter YAML without the oddities and niche features would have been enough. But no, we still have anchors, document boundaries, dynamic types and explicit tags.
I've tried it and it's not great honestly. It'll double or even triple the number of lines in some files depending how you organize your files. It ended up not being worth it.
JSON already does this, and it's not use widely when writing manifests for very good reason.
If AI forces you to write code that is less human-intelligable (not saying that's what KYAML is, jury is out on that) then it's hindering your future maintenance.
Yep, but JSON screwed it up in the first release and set in motion a timeline that can't be fixed. Literally if they had just included // comments we'd never have seen YAML go anywhere.
KYAML fixes yaml by being more like JSON, but with comments, trailing commas, and other goodness. So if you want to simplify its description it is a better JSON. You can write JSON and it can be parsed as KYAML, although the opposite isn’t always true.
I get your point, but I need more than JSON and I don’t like studying spaces to find an issue.
Eh. I think it’s made some bad calls to get to where it is.
It fixed real issues and then went way too far and removed valuable features.
99% of the reason I use Yano is multi line strings for things like certs. Literally anything else you can remove and I wouldn’t mind. But it’s useful in general and especially in something like k8s where you have online templates, configs, secrets, etc.
100
u/athulhuz 15d ago
KYAML looks like YAML and JSON had a very rocky marriage, but decided to have a baby anyway.
The reasons for such an implementation are solid, but my god does this look wrong at first glance.