This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-11-15
Channels
- # announcements (1)
- # asami (29)
- # babashka (31)
- # beginners (48)
- # calva (39)
- # cljsrn (4)
- # clojure (56)
- # clojure-dev (51)
- # clojure-doc (3)
- # clojure-europe (40)
- # clojure-gamedev (13)
- # clojure-italy (22)
- # clojure-nl (3)
- # clojure-uk (5)
- # cursive (9)
- # datomic (184)
- # events (7)
- # fulcro (8)
- # graalvm (2)
- # jobs (1)
- # malli (6)
- # meander (1)
- # nrepl (5)
- # off-topic (10)
- # pathom (9)
- # polylith (33)
- # portal (2)
- # re-frame (7)
- # reagent (12)
- # releases (3)
- # remote-jobs (3)
- # reveal (27)
- # shadow-cljs (34)
- # sql (1)
- # vim (7)
- # xtdb (62)
I noticed that medatada is not part of the EDN specification, only reader tags, yet the EDN read functions do keep metadata. Is metadata considered part of the formal spec?
I don't know any details but I think there's a trouble with languages that don't support metadata. Here's an old issue mentioning the same thing: https://github.com/edn-format/edn/issues/52#event-84718905
read-string
and clojure.edn/read-string
both support a superset of the edn
specification
clojure itself is a superset of edn
for example, you can parse (clojure.edn/read-string "1/2")
and it is not part of edn
specification.
I think that the idea of the edn
specification is to keep it minimal, to be easily portable, and the ones that want, can implement it own extensions.
for example, cljs do not support Ratios
, if Ratios
were part of edn specification, the cljs version of edn/read-string
would be incomplete.
So do not have ratios in edn spec were a good thing, because allow a full implementation in cljs
Many languages do not have any way to implement metadata so it would be difficult for that to be portable
If I were to do something perverse and create a EDN serialization codec in protobuf, should I support only the official spec or fully support metadata? What about things like ratios?
what problem are you trying to solve?
There you go asking the architect-y questions. Mostly just fooling around to see how easy it is to implement and compare the performance against other options. But if it's viable and people actually want to use it, I might as well do it properly, no?
well I don't think you can answer the question above until you know what people might use it for
metadata, ratios, etc are not edn, they are extensions to edn
I don't get why anyone would want this
like what does it get you that transit doesn't?
Don't get me wrong, I find it difficult to put into words how much I dislike protobuf
But if for some reason the performance and binary size are more important to users than things like ergonomics, visibility and sanity :man-shrugging:
would it be competitive with nippy?
is that b/c of fixed record knowledge?
I'm just trying to figure out in which cell of the multi-dimensional matrix this is interesting
what is the question where this is the best answer?
cross language + fixed schema + ???
nippy isn't fixed schema though is it?
It doesn't just serialize everything you give it. It has a pretty wide range of support, but if you throw some ad-hoc object at it it will break
sure, but you don't have to know it up-front - it's serialization
doesn't protobuff require some prior schema knowledge?
or am I just out of touch with protobuf
that seems ... uninteresting
the schema+perf is the interesting difference
if this is just mapping Clojure types to protobuf, I mean, that's been done
I think if you just google clojure and protobuf, you'll find things
Ghadi was working on a pretty involved protobuf thing for a while but I don't know that he ever got around to releasing it
There's this library developed by a colleague of mine https://github.com/AppsFlyer/pronto
I think I did one like 10 yrs ago when I was comparing to avro, but again was never released
every time I've tried I always decided I hated proto and/or fixed schema so much that I did something else :)
regarding formats, how do transit and fressian hold up? Is there a particular reason to prefer fressian?
I think Stu's conj talk about Fressian lays out the benefits pretty well
Datomic uses Fressian for some of its storage
I think the biggest fork in the road is: do I have some out of band way to tell you about the structure of this data or is that encoded in the data itself? edn, transit, and fressian are all encoding schemes that are both extensible and include the structure in the data. protobuf is not afaik.
so that's why I say that that is the interesting difference if it allows you to also achieve much better performance