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.
INI can be nicer for non-techies due to its flat structure. However, TOML seems to be in an awkward spot: either I want flat approachable (I’ll pick INI) or not (I’ll pick JSONC). Why would I want a mix?
Well, you can still decide how much of the TOML features you actually use in your specific application. For example, I’m currently involved in two projects at $DAYJOB where we read TOML configurations and we don’t make use of the inline tables that OP memes about in either of them.
Ultimately, the big advantage of TOML over INI is that it standardizes all kinds of small INI extensions that folks have come up with over the decades. As such, it has a formal specification and in particular only one specification.
You can assume that you can read the same TOML file from two different programming languages, which you cannot just assume for INI.
They serve largely different use-cases. JSON is good for serializing data. TOML is good for configuration.
.vscodewould like a word.But besides that, I just can’t understand why even someone that hates
JSONwould chooseTOMLoverYAMLfor a config file.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.
Most of production failures in my company in last few years come from people making mistakes in yaml indentation.
JSON5 or even JSONC are as good as TOML for configuration, if not better.
INI can be nicer for non-techies due to its flat structure. However, TOML seems to be in an awkward spot: either I want flat approachable (I’ll pick INI) or not (I’ll pick JSONC). Why would I want a mix?
Well, you can still decide how much of the TOML features you actually use in your specific application. For example, I’m currently involved in two projects at $DAYJOB where we read TOML configurations and we don’t make use of the inline tables that OP memes about in either of them.
Ultimately, the big advantage of TOML over INI is that it standardizes all kinds of small INI extensions that folks have come up with over the decades. As such, it has a formal specification and in particular only one specification.
You can assume that you can read the same TOML file from two different programming languages, which you cannot just assume for INI.
I can’t really decide what extensions my users will face, once they are supported. Therefore too many extensions seems bad to me.
We just document that this is how you write the config file:
[network] bind.host = "127.0.0.1" bind.port = 1234 # etc.And that seems straightforward enough. Yeah, technically users can opt to use inline tables or raw strings or whatever, but they don’t have to.
Configs are often shared, just to explain my reservations with TOML. For my project, I used INI instead.