3 ms·

I'm okay with TOML for something like Cargo configuration, I don't enjoy it for much else though. I always comment the same thing on these sorts of discussions

I'm okay with TOML for something like Cargo configuration, I don't enjoy it for much else though. I always comment the same thing on these sorts of discussions - JSON5 has been really nice to work with if you can fully control all consumer applications of it (since there aren't great libraries for json5 in every language). Certainly nicer than the hellscape that is YAML.

masklinn 3y ago
> I'm okay with TOML for something like Cargo configuration, I don't enjoy it for much else though. Which seems fine given TOML was designed as a stricter and more reliable INI, not a half-assed programming language. Can’t say I’m unhappy to know that when I see a toml file, it’s probably going to be pretty simple (exactly the opposite of the dread I feel when I see a yaml extension).
- paulgb 3y ago
  I think that’s exactly it. TOML is bad at deep hierarchies, but that’s a good thing; it prevents people from trying to model a whole damn AST in it, which is the direction that YAML seems to go.
  - bryanlarsen 3y ago
    Too bad this isn't a high-level comment that can be upvoted and float to the top.
eviks 3y ago
That Cargo config with [Lib] But also [[bin]]
goku12 3y ago
It really depends on what you're configuring. I like TOML for most cases since it has the right balance of simplicity and expressiveness. JSON could in theory support everything that TOML can - but it can be jarring to look a large config file with just brackets/parenthesis to demarcate blocks. Even YAML finds its niche applications. I don't think JSON or TOML are good substitutes for YAML in case of Kubernetes. Kubernetes needs a single format that can act as a config language (in case of spec) and as a serialization format (in case of state). YAML fulfills that without being overly verbose. We probably shouldn't get too attached to a config language.
- seabass-labrax 3y ago
  Internally, Kubernetes uses a key-value structure, and it doesn't mind what syntax you use to write your configuration files as long as it is passed via the HTTP+JSON API correctly. It's a relatively pedantic detail, but I think it supports the argument that YAML is the best tool for the job currently. Kubernetes' architecture would make it trivial to add TOML, XML or even s-expression support into the CLI tooling, but people don't seem to particularly want to.
  - mdaniel 3y ago
    to the very best of my knowledge, its input api payloads are always content-type:application/json; one can see this in effect via `kubectl --v=100 apply -f some.yaml` and watch it serialize that yaml to json _then_ POST it
  - goku12 3y ago
    Thanks for adding. Your argument demonstrates that there is an optimum human-friendly representation for each data.

masklinn 3y ago

> I'm okay with TOML for something like Cargo configuration, I don't enjoy it for much else though. Which seems fine given TOML was designed as a stricter and more reliable INI, not a half-assed programming language. Can’t say I’m unhappy to know that when I see a toml file, it’s probably going to be pretty simple (exactly the opposite of the dread I feel when I see a yaml extension).

paulgb 3y ago
I think that’s exactly it. TOML is bad at deep hierarchies, but that’s a good thing; it prevents people from trying to model a whole damn AST in it, which is the direction that YAML seems to go.
- bryanlarsen 3y ago
  Too bad this isn't a high-level comment that can be upvoted and float to the top.

eviks 3y ago

That Cargo config with [Lib] But also [[bin]]

goku12 3y ago

It really depends on what you're configuring. I like TOML for most cases since it has the right balance of simplicity and expressiveness. JSON could in theory support everything that TOML can - but it can be jarring to look a large config file with just brackets/parenthesis to demarcate blocks. Even YAML finds its niche applications. I don't think JSON or TOML are good substitutes for YAML in case of Kubernetes. Kubernetes needs a single format that can act as a config language (in case of spec) and as a serialization format (in case of state). YAML fulfills that without being overly verbose. We probably shouldn't get too attached to a config language.

seabass-labrax 3y ago
Internally, Kubernetes uses a key-value structure, and it doesn't mind what syntax you use to write your configuration files as long as it is passed via the HTTP+JSON API correctly. It's a relatively pedantic detail, but I think it supports the argument that YAML is the best tool for the job currently. Kubernetes' architecture would make it trivial to add TOML, XML or even s-expression support into the CLI tooling, but people don't seem to particularly want to.
- mdaniel 3y ago
  to the very best of my knowledge, its input api payloads are always content-type:application/json; one can see this in effect via `kubectl --v=100 apply -f some.yaml` and watch it serialize that yaml to json _then_ POST it
- goku12 3y ago
  Thanks for adding. Your argument demonstrates that there is an optimum human-friendly representation for each data.