To me, that makes it sound like you’re writing too much and too complex yaml files manually, and/or that you don’t have good enough CI to catch invalid configurations. Unless, of course, you have very few prod failures overall, and the few that happen are due to yaml indentation, which I still think is a bit weird, since an invalid config caused by incorrect indentation should ideally be caught at compile time (if you’re generating code from the yaml) or by some linter or something (if you’re using it for config).
In yaml a mistake in indentation can easily result in a business error without config becoming invalid.
Writing too much complex configs in files is a problem too ofc, we ended up moving a lot of stuff like that to a DB lately.
I’m not a fan of indentation being logically meaningful not just in yaml. If you mess up indentation in python you can also get a technically valid code that’s wrong logically.
VSCode is Electron, i.e. a webpage, so it’s not hugely surprising that they opted for the natively supported JavaScript Object Notation. And also shows that they don’t care for using the right tool for the job to begin with.
Personally, I much prefer TOML over YAML, because it does not have significant whitespace, and because you can read the spec in a reasonable amount of time. It just has so much less complexity, while still covering the vast majority of use-cases perfectly well.
I’ll agree that significant whitespace can be a PITA (one of the reasons I prefer json over yaml), but at the same time I think improper or lacking indentation hurts readability even more than significant whitespace. Toml basically encourages a completely flat structure, where objects and sub-objects are defined all over the place. At that point, I much prefer an enforced structure with whitespace.
I can understand the sentiment and would 100% agree for programming languages.
But personally I actually like that it encourages a flat structure, because you do not want to be yakshaving the structure of your config file. Too much nesting means you will sooner or later run into configuration keys being nested under the wrong category, because your project context changed over time.
And well, as I’ve argued in a few other comments already, I think non-techie users have a disproportionally simpler time when no nesting is used. They understand the concept of a heading and then just adding a line underneath the appropriate heading is really intuitive.
You can just tell them to add the line certificate="/tmp/cert.crt" under [network.tls] and they will find a line in their config file which actually reads [network.tls] and they can just paste that line as-is.
You need some awkward explanation where they should nest it, or an explanation that e.g. “network.tls” translates to nesting.
They will ask whether they should indent the line you sent them.
Well, and it’s also surprisingly difficult to explain between which braces they should put the text, and that’s at the end of the braces, but not after the braces etc., if you’re talking to them on a call.
It’s not even that I’m completely enamored with TOML, but this aspect is certainly growing on me…
.vscodewould like a word.But besides that, I just can’t understand why even someone that hates
JSONwould chooseTOMLoverYAMLfor a config file.Most of production failures in my company in last few years come from people making mistakes in yaml indentation.
To me, that makes it sound like you’re writing too much and too complex yaml files manually, and/or that you don’t have good enough CI to catch invalid configurations. Unless, of course, you have very few prod failures overall, and the few that happen are due to yaml indentation, which I still think is a bit weird, since an invalid config caused by incorrect indentation should ideally be caught at compile time (if you’re generating code from the yaml) or by some linter or something (if you’re using it for config).
In yaml a mistake in indentation can easily result in a business error without config becoming invalid.
Writing too much complex configs in files is a problem too ofc, we ended up moving a lot of stuff like that to a DB lately.
I’m not a fan of indentation being logically meaningful not just in yaml. If you mess up indentation in python you can also get a technically valid code that’s wrong logically.
VSCode is Electron, i.e. a webpage, so it’s not hugely surprising that they opted for the natively supported JavaScript Object Notation.
And also shows that they don’t care for using the right tool for the job to begin with.Personally, I much prefer TOML over YAML, because it does not have significant whitespace, and because you can read the spec in a reasonable amount of time. It just has so much less complexity, while still covering the vast majority of use-cases perfectly well.
I’ll agree that significant whitespace can be a PITA (one of the reasons I prefer json over yaml), but at the same time I think improper or lacking indentation hurts readability even more than significant whitespace. Toml basically encourages a completely flat structure, where objects and sub-objects are defined all over the place. At that point, I much prefer an enforced structure with whitespace.
I can understand the sentiment and would 100% agree for programming languages.
But personally I actually like that it encourages a flat structure, because you do not want to be yakshaving the structure of your config file. Too much nesting means you will sooner or later run into configuration keys being nested under the wrong category, because your project context changed over time.
And well, as I’ve argued in a few other comments already, I think non-techie users have a disproportionally simpler time when no nesting is used. They understand the concept of a heading and then just adding a line underneath the appropriate heading is really intuitive.
You can just tell them to add the line
certificate="/tmp/cert.crt"under[network.tls]and they will find a line in their config file which actually reads[network.tls]and they can just paste that line as-is.With nesting, they’d need to add it under here:
network: { tls: { certificate: "/tmp/cert.crt" } }Which means:
It’s not even that I’m completely enamored with TOML, but this aspect is certainly growing on me…