5 ms·

TOML is not much better either. Large TOML documents suck to work with.

by voidfunc 4y ago

vaylian 4y ago
Which format do you prefer for large documents/configurations?
- inferiorhuman 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. 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
  I thought about it long and hard and went with one file per setting in my app. There is a tree of defaults from the repo and a tree of config which overlays it with any changes.
  - tqkxzugoaupvwqr 4y ago
    Uff, lots of files. My first idea after reading your comment was to consolidate the settings into two key=value files (simplified INI files): One for defaults, one for custom settings.
    - forgotmypw17 4y ago
      It's a couple thousand files, nothing a modern filesystem can't handle.
      - imtringued 4y ago
        This is how the node_modules blackholes were created on earth. One package at a time until they reached critical mass.
        forgotmypw17 4y ago
        It's definitely a tradeoff, but I decided to do it this way for ease of maintenance. Most of the settings are 0/1 or a one-line string, but a few are multi-line. This also allows me to store templates under the same tree, which is where most of the code lives. Because I use one call for getting and setting a config setting, I can probably rearchitect it in the future to e.g. a key-value store. But for now, it just makes it so easy to maintain from the shell, and to create overlay themes, and so many other possibilities that I'd never dreamed of before.
- enneff 4y ago
  CUE is far and away the best tool for this job I have seen. https://cuelang.org/ https://cuelang.org/
- IshKebab 4y ago
  JSON5 is the best option today, though I haven't tried CUE which people keep mentioning. Their website is not very accessible.
- baq 4y ago
  dhall. strongly typed configs. if only people could get past the terror and see the light...
- Ygg2 4y ago
  The config clock - http://mikehadlow.blogspot.com/2012/05/configuration-complexity-clock.html http://mikehadlow.blogspot.com/2012/05/configuration-complex...

TOML is not much better either. Large TOML documents suck to work with.

vaylian 4y ago

Which format do you prefer for large documents/configurations?

inferiorhuman 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. 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
I thought about it long and hard and went with one file per setting in my app. There is a tree of defaults from the repo and a tree of config which overlays it with any changes.
- tqkxzugoaupvwqr 4y ago
  Uff, lots of files. My first idea after reading your comment was to consolidate the settings into two key=value files (simplified INI files): One for defaults, one for custom settings.
  - forgotmypw17 4y ago
    It's a couple thousand files, nothing a modern filesystem can't handle.
    - imtringued 4y ago
      This is how the node_modules blackholes were created on earth. One package at a time until they reached critical mass.
      - forgotmypw17 4y ago
        It's definitely a tradeoff, but I decided to do it this way for ease of maintenance. Most of the settings are 0/1 or a one-line string, but a few are multi-line. This also allows me to store templates under the same tree, which is where most of the code lives. Because I use one call for getting and setting a config setting, I can probably rearchitect it in the future to e.g. a key-value store. But for now, it just makes it so easy to maintain from the shell, and to create overlay themes, and so many other possibilities that I'd never dreamed of before.
enneff 4y ago
CUE is far and away the best tool for this job I have seen. https://cuelang.org/ https://cuelang.org/
IshKebab 4y ago
JSON5 is the best option today, though I haven't tried CUE which people keep mentioning. Their website is not very accessible.
baq 4y ago
dhall. strongly typed configs. if only people could get past the terror and see the light...
Ygg2 4y ago
The config clock - http://mikehadlow.blogspot.com/2012/05/configuration-complexity-clock.html http://mikehadlow.blogspot.com/2012/05/configuration-complex...