4 ms·

Comparison of configuration file languages (2016)

21 points by aleyan 2y ago

itohihiyt 2y ago
I love me an INI. By far, IMO, the best human readable config syntax. Sure it's got some gotchas, like all old formats (CSV) there's no spec. But if I have the choice I'd go INI. It's simple and leaves the choices up to the program that's reading the file, because everything is a string. To me there's no difference in this articles argument that with INI people would have to remember about the idiosyncrasies of the python implementation related to comments, and people having to know and learn the correct syntax of TOML. I'd say remembering when and where you can comment is easier too. Either way it's personal preference. I do occasionally like to reread this though (because I'm boring): https://github.com/madmurphy/libconfini/wiki/An-INI-critique-of-TOML https://github.com/madmurphy/libconfini/wiki/An-INI-critique...
- codeflo 2y ago
  You’d probably be surprised how often people have to create config files programmatically. With properly specified formats, you can serialize the configuration, which means nesting and string escapes are taken care of automatically. With half-baked custom formats, you have to resort to string replacement and praying. Having said that, there’s an official RFC for CSV, and INI files are de-facto specified by Microsoft’s implementation.
  - itohihiyt 2y ago
    Yeah, half baked anything is going to screw you over. INI files are certainly programmatically serialisable, otherwise they wouldn't exist. It does move the datatypes to the program rather than being encoded in the config though, which adds to program overhead. Horses for courses though, with greater flexibility comes greater potential to f*uk it up.
- aeurielesn 2y ago
  TOML is a monstrosity and I'm terrified Python is backing it up. I'd love to see more HCL.
oezi 2y ago
If JSON would allow comments (and trailing commas would be nice as well), then I think it would be a strong contender for a config format as well.
- anon7000 2y ago
  Many configuration files for tools in the JS ecosystem actually do allow both of those through json5 (https://json5.org/ https://json5.org/)
- massifist 2y ago
  Also, allowing unquoted names.
OskarS 2y ago
More and more the last couple of years, I’ve started to realize that ”configuration languages” are just a bad idea. Please, for the love of all that is holy, just let us use a real programming language. For simple declarative configuration, it’s no more difficult to use Python (or Lua or whatever) than YAML, and for complex configuration (looking at you, YAML files for GitLab CI), it’s an absolute godsend to be able to use real if-statements and for-loops. If security/runtime is a concern, you can sandbox it or use something like Starlark. JSON is a fine over-the-wire format, but can’t we leave YAML in the dustbin and just do it ”properly” from now on? Please?
- aziis98 2y ago
  I hope one day people will realize that configuration languages can just be implemented by adding a "--run-total-sandboxed" to their favorite language i.e. a flag that disables while loops and recursion making the language non Turing complete and that runs the program in a sandbox without direct external access. This would be far better than all random configuration languages out there and far more extensible.
- derriz 2y ago
  I disagree - I do not want to involve execution to interpret the contents of a config file. I at least want to be able to trivially determine if two config components are equal by simple visual inspection.
- 9dev 2y ago
  Hard pass. There is a lot of software I am forced to run without wanting to involve myself with it. If your tool is so complex to warrant a need for a full programming language in its config files, to me that smells of another issue, but generally I just want a set of knobs to tweak behaviour. I’m so over having to learn Go templates for a metrics exporter, or the need to write booleans as True or False for python apps, or some obscure Erlang syntax for RabbitMQ, or the batshit crazy APT config file syntax, or Apache's weird XML files… Just settle for a simple format and offer to load custom modules for those that need them.
  - 2y ago
deleted 2y ago
[deleted]

21 points by aleyan 2y ago

I love me an INI. By far, IMO, the best human readable config syntax. Sure it's got some gotchas, like all old formats (CSV) there's no spec. But if I have the choice I'd go INI. It's simple and leaves the choices up to the program that's reading the file, because everything is a string. To me there's no difference in this articles argument that with INI people would have to remember about the idiosyncrasies of the python implementation related to comments, and people having to know and learn the correct syntax of TOML. I'd say remembering when and where you can comment is easier too. Either way it's personal preference. I do occasionally like to reread this though (because I'm boring): https://github.com/madmurphy/libconfini/wiki/An-INI-critique-of-TOML https://github.com/madmurphy/libconfini/wiki/An-INI-critique...

codeflo 2y ago
You’d probably be surprised how often people have to create config files programmatically. With properly specified formats, you can serialize the configuration, which means nesting and string escapes are taken care of automatically. With half-baked custom formats, you have to resort to string replacement and praying. Having said that, there’s an official RFC for CSV, and INI files are de-facto specified by Microsoft’s implementation.
- itohihiyt 2y ago
  Yeah, half baked anything is going to screw you over. INI files are certainly programmatically serialisable, otherwise they wouldn't exist. It does move the datatypes to the program rather than being encoded in the config though, which adds to program overhead. Horses for courses though, with greater flexibility comes greater potential to f*uk it up.
aeurielesn 2y ago
TOML is a monstrosity and I'm terrified Python is backing it up. I'd love to see more HCL.

oezi 2y ago

If JSON would allow comments (and trailing commas would be nice as well), then I think it would be a strong contender for a config format as well.

anon7000 2y ago
Many configuration files for tools in the JS ecosystem actually do allow both of those through json5 (https://json5.org/ https://json5.org/)
massifist 2y ago
Also, allowing unquoted names.

OskarS 2y ago

More and more the last couple of years, I’ve started to realize that ”configuration languages” are just a bad idea. Please, for the love of all that is holy, just let us use a real programming language. For simple declarative configuration, it’s no more difficult to use Python (or Lua or whatever) than YAML, and for complex configuration (looking at you, YAML files for GitLab CI), it’s an absolute godsend to be able to use real if-statements and for-loops. If security/runtime is a concern, you can sandbox it or use something like Starlark. JSON is a fine over-the-wire format, but can’t we leave YAML in the dustbin and just do it ”properly” from now on? Please?

aziis98 2y ago
I hope one day people will realize that configuration languages can just be implemented by adding a "--run-total-sandboxed" to their favorite language i.e. a flag that disables while loops and recursion making the language non Turing complete and that runs the program in a sandbox without direct external access. This would be far better than all random configuration languages out there and far more extensible.
derriz 2y ago
I disagree - I do not want to involve execution to interpret the contents of a config file. I at least want to be able to trivially determine if two config components are equal by simple visual inspection.
9dev 2y ago
Hard pass. There is a lot of software I am forced to run without wanting to involve myself with it. If your tool is so complex to warrant a need for a full programming language in its config files, to me that smells of another issue, but generally I just want a set of knobs to tweak behaviour. I’m so over having to learn Go templates for a metrics exporter, or the need to write booleans as True or False for python apps, or some obscure Erlang syntax for RabbitMQ, or the batshit crazy APT config file syntax, or Apache's weird XML files… Just settle for a simple format and offer to load custom modules for those that need them.
- 2y ago

deleted 2y ago

[deleted]