5 ms·

Try edn: https://learnxinyminutes.com/docs/edn/ https://learnxinyminutes.com/docs/edn/

masklinn 3y ago
I like edn but I’m not convinced it’s great for configuration. 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.
- dkersten 3y ago
  I love EDN (especially the integrant extensions) for configuration of the stack — that is, dependency injection and so on, the developer-focused configuration. 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.
  - jmkr 3y ago
    Why do you love edn? Specifically I also like edn, but I always felt like my use of it was glorified json. 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.
    - dkersten 3y ago
      I suppose mostly superficial reasons such as liking the keyword syntax better that using string keys in json, but also the richer set of data types (like sets), although that mostly doesn’t matter in practice, but it is very nice when using Clojure since the Clojure types just work. As an interchange or storage format it’s also nice to be able to store Clojure types and get them back the way they were out in, which if using json you would lose some information. Mainly it’s just personal taste and no deep reasons.
dkersten 3y ago
I especially love the Integrant[1] version which uses the E from EDN (extensible) to add references: {:adapter/jetty {:port 8080, :handler #ig/ref :handler/greet} :handler/greet {:name "Alice"}} [1] https://github.com/weavejester/integrant https://github.com/weavejester/integrant
eternityforest 3y ago
Too many features that can't be represented in standard programming language constructs.. JSON-alikes are opinionated. They don't let you do stuff that requires a plugin for the parser to work with

I like edn but I’m not convinced it’s great for configuration. 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.

dkersten 3y ago
I love EDN (especially the integrant extensions) for configuration of the stack — that is, dependency injection and so on, the developer-focused configuration. 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.
- jmkr 3y ago
  Why do you love edn? Specifically I also like edn, but I always felt like my use of it was glorified json. 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.
  - dkersten 3y ago
    I suppose mostly superficial reasons such as liking the keyword syntax better that using string keys in json, but also the richer set of data types (like sets), although that mostly doesn’t matter in practice, but it is very nice when using Clojure since the Clojure types just work. As an interchange or storage format it’s also nice to be able to store Clojure types and get them back the way they were out in, which if using json you would lose some information. Mainly it’s just personal taste and no deep reasons.

dkersten 3y ago

I especially love the Integrant[1] version which uses the E from EDN (extensible) to add references: {:adapter/jetty {:port 8080, :handler #ig/ref :handler/greet} :handler/greet {:name "Alice"}} [1] https://github.com/weavejester/integrant https://github.com/weavejester/integrant

eternityforest 3y ago

Too many features that can't be represented in standard programming language constructs.. JSON-alikes are opinionated. They don't let you do stuff that requires a plugin for the parser to work with