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?
Why do so many tools have JSON config files?
31–40 of 78 posts
Re: Why do so many tools have JSON config files?
#32[dead]
Re: Why do so many tools have JSON config files?
#33I 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.
Re: Why do so many tools have JSON config files?
#34Re: Why do so many tools have JSON config files?
#35> A lot of tech folks resist documentation because they think it provides them with job security. No, we're just lazy.
[deleted]
Re: Why do so many tools have JSON config files?
#36Earlier quoted context omitted.
Can you show an example of how you use SQLite for _config_ files?
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.
Re: Why do so many tools have JSON config files?
#37> 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.
Re: Why do so many tools have JSON config files?
#38Re: Why do so many tools have JSON config files?
#39For 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
Re: Why do so many tools have JSON config files?
#40I 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.