I'd argue that for code, yes, JSON is vastly closer to computer structures.
I think this is the real "why do so many tools have JSON config files": because it's just a literal notation, for basic data structures, that looks a lot like what many programming languages natively do, what their data structures natively are. The answer to the post is: it's mechanistic sympathy.
For humans, I do find TOML to be a lot easier to manage. Even if you have a really good editor that takes care of all the quoting/nesting/comma concerns for you, even if you have jsonc or json5 with comments, it's still not as easy/friendly as a big flat file with sections in it.
I find the toml structure impossible to follow as a human. It's like a complicated nested ini file. Asinine and terrible. I don't need a fancy editor (and I don't have one) to close my quotes and brackets. jq checks the syntax easily. On the other hand I have to crash my services to find out I nested shit wrong in toml because there's no structure
What are your thoughts on ini? My perspective is that >9/10 toml's are just ini files, straight up. The nesting seems rare, and rarely confusing to me.
I obviously disagree about the ease of json editing. jq tells me errors, sure. But formats where we don't need bespoke tooling, where notepad.exe work fine, are I think probably what config files should be more like.
My only experience with toml is complicated nested ones because I'm sure that the maintainers outgrew whatever was simple. Off the top my head it's just containerd config. Yaml probably a better choice than json and ini is fine if it gets the job done, but it's it really more than .env? My opinion is the env should do a lot of lifting anyway. I'm thinking there's always "tooling." My toml might syntax but be logically incorrect all the formats have that problem and linting doesn't stop at json. Like changing my containerd config I don't really know if it took or not
Comments
Reading and writing json is so much easier than reading or writing toml imo
I'd argue that for code, yes, JSON is vastly closer to computer structures.
I think this is the real "why do so many tools have JSON config files": because it's just a literal notation, for basic data structures, that looks a lot like what many programming languages natively do, what their data structures natively are. The answer to the post is: it's mechanistic sympathy.
For humans, I do find TOML to be a lot easier to manage. Even if you have a really good editor that takes care of all the quoting/nesting/comma concerns for you, even if you have jsonc or json5 with comments, it's still not as easy/friendly as a big flat file with sections in it.
I find the toml structure impossible to follow as a human. It's like a complicated nested ini file. Asinine and terrible. I don't need a fancy editor (and I don't have one) to close my quotes and brackets. jq checks the syntax easily. On the other hand I have to crash my services to find out I nested shit wrong in toml because there's no structure
What are your thoughts on ini? My perspective is that >9/10 toml's are just ini files, straight up. The nesting seems rare, and rarely confusing to me.
I obviously disagree about the ease of json editing. jq tells me errors, sure. But formats where we don't need bespoke tooling, where notepad.exe work fine, are I think probably what config files should be more like.
My only experience with toml is complicated nested ones because I'm sure that the maintainers outgrew whatever was simple. Off the top my head it's just containerd config. Yaml probably a better choice than json and ini is fine if it gets the job done, but it's it really more than .env? My opinion is the env should do a lot of lifting anyway. I'm thinking there's always "tooling." My toml might syntax but be logically incorrect all the formats have that problem and linting doesn't stop at json. Like changing my containerd config I don't really know if it took or not