Some advantages of EDN:

* Can represent sets `#{1 2 3 4 "foo" "bar" true false}` (JSON only supports arrays)

* Maps/sets can contain arbitrary EDN as keys/values. `{[1 2] "foo", 5 :a, "5" :b, true -1, false 5}` or `#{[1 2] #{3 4} (5 6)}` (JSON only supports string keys on "objects")

* Supports clojure types like keywords (`:foo`, `:bar/baz`) and symbols (`foo`, `bar/baz`), and can be extended to support other values as well

EDN also contains support for date and UUID literals, the former of which is a huge pain when using JSON and needing to communicate which standard you're using and remember to encode/decode on each side of the wire.

Plus you can even write your own reader literals to enhance your data format. Aero does this well/horribly depending on your taste but it's a cool mechanism for declarative formats.

I could probably look it up myself, but does EDN support comments?

Yep, two types in fact, line comments with ; and a discard sequence - you can tag code that is read (so it must be correct), but then discarded. We have edn files that are well documented with comments.

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

I thought so — then it is strictly better than JSON.

1. Objects are sets of keys

2. JS has Map/Set which allow other composite types as keys and can be converted to objects for JSON serialization then deserialize back to Map/Set.

Yeah but still you have to admit, there's quite a lot more friction and ambiguity in that approach. Do I represent a map as

    [
      ["key", "value"],
      ["otherKey", "otherValue"]
    ]  
  

or

    [
      {"key": "key", "value": "value"},
      {"key": "otherKey", "value":"otherValue"}
    ]  

or something else? And how can I distinguish between values which just happen to look like maps but are actually not maps? And what if the service I'm talking to does it differently? What if I'm comparing or sorting two JSON values, don't I have to modify the equality/hashcode/ordering logic now to interpret

    [
      ["key", "value"],
      ["otherKey", "otherValue"]
    ] 

and

    [
      ["otherKey", "otherValue"],
      ["key", "value"]
    ] 

as being equal and implement a new hashcode/ordering which treats them as equal?

Quite a lot easier when this is just native to the format.

JS Map/Set use referential equality, which is pretty worthless if you aren't dealing with primitives.

> If using the same business logic is one of the main reasons, why not JavaScript / TypeScript?

Because Clojure is better designed. As are many other languages.

Arguably the JVM is a better backend platform, due to better performance, observability, scalability, parallelism (it is not even a competition, and then we haven’t even talked about Loom), plus the least objective point of mine, more stable, battle tested libraries.

That's like saying that C++ is a better backend platform than the JVM due to better performance. For 95% of business web apps out there it doesn't matter, I mean, multiple business with evaluations in the billions of dollars have been created with runtimes 50x slower than nodejs.

Nodejs competes with Java in single threaded performance, I'll say normal JS code is faster than normal Java code. For web services that are IO bound, nodejs still competes with Java unless you go with all the batshit crazy complex reactive stuff in the Java world, supposedly is going to get better with the new green threads implementation.

You may have missed the other 10 reasons I listed besides performance.

Also, no JS code will be faster than Java. While both have insanely good JIT compilers that can output some truly, often surprisingly great machine code, java is all-around faster, if for no other reason, due to its killer GCs.

>That's like saying that C++ is a better backend platform

C++ isn't even a platform, period. It provides no runtime or anything else other than the language. If you build on top of the JVM ecosystem, similar to NET you get a cross platform, extremely performant ecosystem with millions if not billions invested into it basically for free.

And of course you can build a billion dollar company on a crappy tech stack, but if you had built it on a good one you'd still be a billion dollar company and be even better off. What a strange argument, you ought to make the best technical choice you can, it's a core part of anything you built. And getting a 10x performance on the JVM vs say Python, or smooth, non error prone concurrency in Clojure is a significant benefit.

In particular in business applications were you usually deal with data transformations, the single-threaded, mutable state type of design of some languages is awful. Clojure in particular was exactly made for this practical use case.

JavaScript is one of the few languages that works well both in the browser and on the server side. I don't think this is the time or the place to explain why I didn't write my software in JavaScript — let's just say that I don't think I could handle the incidental complexity in my team of size 1.

As for JSON, others have replied, but my point was perhaps not very well made. It's not just the limitations of JSON itself. By using the same language on both sides, I can avoid adapting to the limitations of any transit format. In other words, I can (pretty much) pass native data structures through and get them out on the other side. In my case, that means not just maps and vectors, but also sets, keywords, or UUIDs. Can this be done with JSON? Sure! But then I'd have an entirely new bug area to deal with (encoding/decoding, forgetting to coerce, etc).

I don’t use Clojure but based on a quick search, EDN is extensible so you can serialize things like datetimes and UUIDs with type information rather than as plain strings