I wish everyone would embrace Amazon's Ion format. Of the data serialization formats it seems the most reasonable with the exception that it can encode S-expressions (so like having data serialization within your data serialization), so it is a bit excessive.
For Caddy we chose JSON because it's fairly universal, maps nearly 1:1 with Go structs (useful for initializing an extensible server), and nearly everything else compiles to JSON one way or another, so you can choose your own config format, really: https://caddyserver.com/docs/config-adapters
1: Because JSON is a very easy serialization format to work with. I suspect these tools all have configuration classes / objects that are deserialized straight from the config file.
2: I suspect a lot of these tools are written in Javascript, and in Javascript JSON is very easy to work with.
For our internal tooling we use something similar to a bash profile config file with name/value pairs separated by linebreaks. So, our configs look something like:
because JSON is in the following sense "universal":
every format/structure that has numbers, strings, booleans, null/none, finite lists of items, and string-indexed records of items already contains JSON
and that's pretty much the barebones you need for a configuration language
JSON still a very simple and useful format and being natively supported on the web and by javascript basically guarantees its universality. Native comments would be nice though. But to be fair even Douglas Crockford suggested using comments in JSON was fine as long as you stripped them out before parsing.
<whispers>but Lua tables are even better.</whispers>
SQLite is a tiny relational db that essentially runs right in the same folder as your application. No connection other than connecting from the app itself to the SQLite.db sitting next to it.
I don't know about others, but I use JSON because it's in the standard Go library, and most of the times, I rather use something weird than add a dependency.
Let me guess... if they're a form of Lisp, did someone add jndi support, then made it possible to print to the console while the string gets read and finally made it executable because who wouldn't want a LISP for-loop in an Oracle connection string? On to the next RCE...
It would be too easy to have every option in a config file documented in comments in the default config file. Think of the poor tutorial industry. It may even make chatbots less useful.
TOML is a better format for configuration files IMO, if not for many reasons, primarily because TOML accepts comments.
However, one annoying thing for TOML was the lack of schema, and the reliance on JSON Schema for that. Which I decided to tackle years ago when I started the TOML Schema project. In the past few months I leveraged code agents to take to the finish line and got something compelling: tomlschema.org
Interesting. The website says that it's "validation-focused". I don't know how that plays out for TOML, but the lack of focus in json schema to define an interface in addition to validation can be very frustrating. Most of the time I would rather trade off some expressitivity in terms of validation in favor of having a defined typed interface into the validated data.
JSON is obviously a poor choice. It's job is to interchange data, produced and parsed by computers.
ESR had the idea of writing configuration in English. It didn't gain traction at the time, but we have LLMs now. It might be a good idea to revisit the idea of accepting plain english. The LLM output could then be any format that's easy and unambiguous to parse.
I'm not sure why there's a problem before even trying.
Say for instance you have a program that keeps recipes. In your configuration file, there's settings such as metric/imperical units, allergies, diets, type of stove in your kitchen, and some theming (font, size, color...). You put them all in a file that you can parse, but aunt tillie messes up the formatting and the program breaks.
Instead of changing the config by hand, an LLM could supply the diff according to instructions in English. I really don't see why this would be "Terrible for prod". If the LLM screws up, you're simply back to square 1 and aunt tillie will call you just like she would before she had an LLM to fix her computer.
I wish everyone would embrace Amazon's Ion format. Of the data serialization formats it seems the most reasonable with the exception that it can encode S-expressions (so like having data serialization within your data serialization), so it is a bit excessive.
https://en.wikipedia.org/wiki/Ion_(serialization_format)
For Caddy we chose JSON because it's fairly universal, maps nearly 1:1 with Go structs (useful for initializing an extensible server), and nearly everything else compiles to JSON one way or another, so you can choose your own config format, really: https://caddyserver.com/docs/config-adapters
> A lot of tech folks resist documentation because they think it provides them with job security.
No, we're just lazy.
Occam's Razor at it's finest. I'm not trying to screw others over. I just want to not write sometimes.
It's readable, it's easy, it gets the job done.
I don't think that's necessarily lazy, it's just efficient
> It's readable, it's easy
That's what I am saying about my ruby codes as well. Still my boss wanted proper commit messages
Just the commit message history alone was likely bigger than an average config file in total.
> Why do so many tools have JSON config files‽
1: Because JSON is a very easy serialization format to work with. I suspect these tools all have configuration classes / objects that are deserialized straight from the config file.
2: I suspect a lot of these tools are written in Javascript, and in Javascript JSON is very easy to work with.
For our internal tooling we use something similar to a bash profile config file with name/value pairs separated by linebreaks. So, our configs look something like:
env=staging
db=0.0.0.0
#descriptive comment
etc=true
ini file format is pretty much this
[section_name]
key=value
key=value
because JSON is in the following sense "universal":
every format/structure that has numbers, strings, booleans, null/none, finite lists of items, and string-indexed records of items already contains JSON
and that's pretty much the barebones you need for a configuration language
(of course you can argue about the syntax)
Lack of comments is pretty big though for a human editable config.
It’s just one person’s opinion, but I think two things are true enough, here…
1) JSON is pretty darn good for storing configuration. Everything speaks it, and a pretty printed one is very readable/tweakable in a pinch.
2) If you insist that someone manually edit a significant amount of it, you kinda fucked up.
Just my opinion, but it feels like two separate things.
JSON still a very simple and useful format and being natively supported on the web and by javascript basically guarantees its universality. Native comments would be nice though. But to be fair even Douglas Crockford suggested using comments in JSON was fine as long as you stripped them out before parsing.
<whispers>but Lua tables are even better.</whispers>
It's so simple and straightforward, and that's why Douglas Crockford claims he "discovered" it, rather than invented it.
JSON just works, everywhere, all the time. Sometimes I'll use SQLite if there is a particular need.
Can you show an example of how you use SQLite for _config_ files?
SQLite is a tiny relational db that essentially runs right in the same folder as your application. No connection other than connecting from the app itself to the SQLite.db sitting next to it.
I think your emphasis might be in the wrong place...SQLite for config makes enough sense, but as a config _file_?
Not entirely. Because where would I configure the location of the SQLite location/connection then?
Given what I know about it (single file, no auth, and such by default) I sort of understand the ”file” part I think. But not the ”config” part.
> Why do so many tools have JSON config files‽
Because XML hasn't been cool for about two decades. And suggesting .ini would you laughed out of the room into retirement.
I don't know about others, but I use JSON because it's in the standard Go library, and most of the times, I rather use something weird than add a dependency.
Because JSON is native to the lingua franca of the internet: Java-/Ecmascript.
It fits into the poor choices we made, <-- Parse error
Somewhat off topic, but Oracle database connection strings seem to be a form of Lisp. It makes me wonder why they would choose that.
Let me guess... if they're a form of Lisp, did someone add jndi support, then made it possible to print to the console while the string gets read and finally made it executable because who wouldn't want a LISP for-loop in an Oracle connection string? On to the next RCE...
It would be too easy to have every option in a config file documented in comments in the default config file. Think of the poor tutorial industry. It may even make chatbots less useful.
TOML is a better format for configuration files IMO, if not for many reasons, primarily because TOML accepts comments.
However, one annoying thing for TOML was the lack of schema, and the reliance on JSON Schema for that. Which I decided to tackle years ago when I started the TOML Schema project. In the past few months I leveraged code agents to take to the finish line and got something compelling: tomlschema.org
Reading and writing json is so much easier than reading or writing toml imo
Interesting. The website says that it's "validation-focused". I don't know how that plays out for TOML, but the lack of focus in json schema to define an interface in addition to validation can be very frustrating. Most of the time I would rather trade off some expressitivity in terms of validation in favor of having a defined typed interface into the validated data.
I find TOML is nowhere near as good as YAML. I'd even rather use jsonc.
Yeah, I just use JSON5, it solves all the issues with normal json
JSON is obviously a poor choice. It's job is to interchange data, produced and parsed by computers.
ESR had the idea of writing configuration in English. It didn't gain traction at the time, but we have LLMs now. It might be a good idea to revisit the idea of accepting plain english. The LLM output could then be any format that's easy and unambiguous to parse.
Absolutely not. We do not want a stochastic program without any actual understanding of the schema to be interpreting config data.
> The LLM output could then be any format that's easy and unambiguous to parse.
Thats the problem isnt it? LLMs arent deterministic. Terrible for prod
I'm not sure why there's a problem before even trying.
Say for instance you have a program that keeps recipes. In your configuration file, there's settings such as metric/imperical units, allergies, diets, type of stove in your kitchen, and some theming (font, size, color...). You put them all in a file that you can parse, but aunt tillie messes up the formatting and the program breaks.
Instead of changing the config by hand, an LLM could supply the diff according to instructions in English. I really don't see why this would be "Terrible for prod". If the LLM screws up, you're simply back to square 1 and aunt tillie will call you just like she would before she had an LLM to fix her computer.
Llms are absolutely deterministic if you want them to be.
Still a terrible idea for config