{:adapter/jetty {:port 8080,
:handler #ig/ref :handler/greet}
:handler/greet {:name "Alice"}}
First off, it shares the desire for extensibility with yaml (in the form of tags), which is a giant trap. And then it’s quite syntactically noisy.
For user-facing configuration I still favour TOML. I think it’s a bit application dependent, sone applications (eg nginx) have complex configuration needs and for that it makes sense to use something more sophisticated, but for many user-facing config settings, a simpler-TOML would be a great fit. Basically just some basic key-value pairs that can be collected into groups. As the article states, the parsing types should perhaps be enforced by the parser not the written config.
I did like integrant, at least I felt like I understood it, unlike component.
There were two things about edn that made it seem better than json to me, tagged elements (and readers), and symbols. I don't remember exactly my use case but I used symbols in edn to something like namespace-resolution for multimethods. It was something like including a file in a classpath or loading a file, dev vs prod kind of config.
Mainly it’s just personal taste and no deep reasons.
JSON-alikes are opinionated. They don't let you do stuff that requires a plugin for the parser to work with