Hacker News Reader

Comment by alex-robbins | Hacker News Reader

It's too bad EDN [1] hasn't seen much adoption outside of the biblical paradise that is the Clojure ecosystem.

[1]: https://en.m.wikipedia.org/wiki/Clojure#Extensible_Data_Nota...

In fact, there doesn't seem to be a spec or standard for it, outside of the de facto standard used by Clojure and the programs in its orbit. I guess nobody's bothered to write a standard, because the people who are already using EDN are doing fine without one, and the people who aren't either don't know what it is or don't see its value.

View on HN

https://github.com/edn-format/edn

I too love edn, but unfortunately most other languages lib abandoned (eg. https://github.com/edn-format/edn-dot-net ). Looking around python seems relatively maintained which is great https://github.com/swaroopch/edn_format/issues

Is there an example of what it looks like in practice? The Wikipedia link above doesn't have it, its citation http://edn-format.org/ seems like it doesn't exist anymore, and this github page doesn't show a sample either.

It's plain old clojure, more examples here https://learnxinyminutes.com/edn/

  { :name "John Doe"
    :age 30
    :languages ["English" "Spanish" "French"]
    :address {:street "123 Main St" :city "Anytown"} }

Hundreds thousand of examples at github, see this comment for an example search link: https://news.ycombinator.com/item?id=42364597

Dont be pessimistic - you are still free to used it.

I used EDN outside of Clojure. The system needed a relatively large amount of config files, and I chose EDN as a better JSON. Looks familiar to everyone, but supports comments - the primary motivation for that choice.

JSON-5 allows a single trailing comma. EDN simply ignores commas. You can have them, trailing or not. But they are really redundant and incur visual noise.

Perhaps EDN can also be improved, but that's a good format. Convenient.

> Perhaps EDN can also be improved

How might you improve EDN?

Maybe with: 1) Unicode escapes in strings. 2) Indentation support for multiline string literals, like in Rust, but even better. 3) Reading with "concrete syntax tree" (make the order of map elements, the comments, whitespaces, etc representable, so that one could write an EDN file with the same formatting as it was read, e.g. after patching it). Not sure if the spec changes are needed / will be helpful for that or better to just implement it in specific parsers.

Excellent ideas, especially having a parser keep order of parsed data.

I wonder if EDN reader/parser for different languages could be written once, then compiled through wasm to c (https://news.ycombinator.com/item?id=38602750) and linked in each language as c library.

Definitely would like to see EDN or slightly improved version as a modern and usable alternative to json/yaml (regardless of https://xkcd.com/927/).

Reply on news.ycombinator.com