To say “YAML has its oddities” is like saying “the ocean is somewhat damp”.
I can only assume that every adoption of YAML has been by people who heard about it being used, but had never actually used it in any depth themselves. To believe otherwise, is to believe that those people willingly opted-in to the ridiculous semantics, syntax and parsers that surround YAML.
But OTOH yaml is so quick and easy to write and read… I think it’s good that it’s being used in stuff like ansible/kubernetes.
I don’t think this is true – how can something be “quick and easy to write and read” when even the YAML parsers themselves are disagree with each other on what’s valid YAML?
I think it’s good that it’s being used in stuff like ansible/kubernetes.
It certainly fits the quality standards of Go software. :-)
I don’t think this is true – how can something be “quick and easy to write and read” when even the YAML parsers themselves are disagree with each other on what’s valid YAML?
Because the problematic bits are <1% of the spec and everyone mostly uses the other 99%.
I think the alternative is not using Kubernetes (and perhaps seriously reflecting on all the wrong life choices made that resulted in thinking one needs Kubernetes in the first place).
Kind of weird for this article not to mention that TOML borrows the basic syntax from INI files that are so ubiquitous on Windows - in that sense it’s not “peculiar” at all and feels very familiar to anyone who’s seen an INI file.
Yes, I’ve seen several takes complaining about the choice of TOML as an “obscure” format, including in Python contexts, when in fact it’s just a formalization of implicit rules of the un-standardized and unpredictable interpretation of INI files (baked into Python’s standard library as configparser, a truly benighted corner of the stacks).
To say “YAML has its oddities” is like saying “the ocean is somewhat damp”.
I can only assume that every adoption of YAML has been by people who heard about it being used, but had never actually used it in any depth themselves. To believe otherwise, is to believe that those people willingly opted-in to the ridiculous semantics, syntax and parsers that surround YAML.
Agreed. I’d rather use XML than YAML.
I’m not sure.
I certainly miss the ability to check whether a document is both syntactically valid and semantically conformant to a schema.
But OTOH yaml is so quick and easy to write and read… I think it’s good that it’s being used in stuff like ansible/kubernetes.
I don’t think this is true – how can something be “quick and easy to write and read” when even the YAML parsers themselves are disagree with each other on what’s valid YAML?
It certainly fits the quality standards of Go software. :-)
Because the problematic bits are <1% of the spec and everyone mostly uses the other 99%.
Just imagine how people would absolutely lose their mind if the same was true about XML.
I’m not saying that 1% isn’t a problem. But I think the syntax conveniences of YAML over XML explain its popularity despite the spec issue.
Regarding go software and kubernetes in particular… Can you name a comparably feature rich and production ready open source alternative?
I agree that kubernetes introduces its own complexity and everything… Yet it’s probably one of the best alternatives we have right now.
I think the alternative is not using Kubernetes (and perhaps seriously reflecting on all the wrong life choices made that resulted in thinking one needs Kubernetes in the first place).
In other words: you can’t. Case closed.
The use of significant white space instantly discounts any “easy to write” claim as bullshit.
Props for a great title, and sticking to the theme with the subheadings of the article.
Kind of weird for this article not to mention that TOML borrows the basic syntax from INI files that are so ubiquitous on Windows - in that sense it’s not “peculiar” at all and feels very familiar to anyone who’s seen an INI file.
Yes, I’ve seen several takes complaining about the choice of TOML as an “obscure” format, including in Python contexts, when in fact it’s just a formalization of implicit rules of the un-standardized and unpredictable interpretation of INI files (baked into Python’s standard library as configparser, a truly benighted corner of the stacks).
Those darn kids! shakes fist
I have the opposite reaction; when I see this it looks weird and foreign because it makes me think it’s intended for use on Windows.