3 ms·

For me JSON comes close to ideal, if comments were part of the spec I'd be hard pressed to want anything else for general purpose config files. HCL or libucl p

For me JSON comes close to ideal, if comments were part of the spec I'd be hard pressed to want anything else for general purpose config files. HCL or libucl probably come in second, not that I particularly care much. TOML is less than ideal with (as was pointed out) nested tables – the problem I ran into is that some valid TOML cannot be serialized with serde.

forgotmypw17 4y ago
Problem with json is editing it manually, especially from a shell
stubish 4y ago
> For me JSON comes close to ideal, if comments were part of the spec I'd be hard pressed to want anything else for general purpose config files. ie. YAML. Write your JSON with comments and parse it with a YAML parser. Most decent libraries spit out readable YAML or even JSON if you tweak it to always quote strings.
- inferiorhuman 4y ago
  No, definitely not YAML. There is way too much complexity with YAML.
  - stubish 4y ago
    There is only way too much complexity with YAML if you try to use it. JSON-with-comments makes perfectly good YAML if you like that. Nobody forces you to allow the more esoteric features into your code base. You don't even need to know they exist. You can even use a library like StrictYAML if you don't trust your coworkers to be sensible.
    - inferiorhuman 4y ago
      Great, now whoever uses your program has to wonder what subset of YAML is supported. JSON's advantage is that it's simple, there's not much to support so you get consistent implementations more readily.
pjerem 4y ago
I really don’t understand why we put JSON everywhere tbf. You are limited to very few types, important ones like dates are missing, JSON is a pain to write and format without a "smart" editor. It’s also a pain to read as soon as you start listing complex things. Not saying here that YAML or TOML are better (though I personally prefer TOML) but more that nothing is really nice. It’s just that if we have to give up on a config format to be easily editable with basic tools, maybe we should have stuck with XLM. At least it had solid format definition and enforcement. It’s a semi-troll but maybe we could have something in between XLM and YAML.

forgotmypw17 4y ago

Problem with json is editing it manually, especially from a shell

stubish 4y ago

> For me JSON comes close to ideal, if comments were part of the spec I'd be hard pressed to want anything else for general purpose config files. ie. YAML. Write your JSON with comments and parse it with a YAML parser. Most decent libraries spit out readable YAML or even JSON if you tweak it to always quote strings.

inferiorhuman 4y ago
No, definitely not YAML. There is way too much complexity with YAML.
- stubish 4y ago
  There is only way too much complexity with YAML if you try to use it. JSON-with-comments makes perfectly good YAML if you like that. Nobody forces you to allow the more esoteric features into your code base. You don't even need to know they exist. You can even use a library like StrictYAML if you don't trust your coworkers to be sensible.
  - inferiorhuman 4y ago
    Great, now whoever uses your program has to wonder what subset of YAML is supported. JSON's advantage is that it's simple, there's not much to support so you get consistent implementations more readily.

pjerem 4y ago

I really don’t understand why we put JSON everywhere tbf. You are limited to very few types, important ones like dates are missing, JSON is a pain to write and format without a "smart" editor. It’s also a pain to read as soon as you start listing complex things. Not saying here that YAML or TOML are better (though I personally prefer TOML) but more that nothing is really nice. It’s just that if we have to give up on a config format to be easily editable with basic tools, maybe we should have stuck with XLM. At least it had solid format definition and enforcement. It’s a semi-troll but maybe we could have something in between XLM and YAML.