Concise Encoding
Languages and libraries
data serialization format
SHOW HN2020
How HN took it
1 positive, 11 neutral or asking, 0 mixed, 10 critical, out of 22 comments about the project. Thread score -0.35.
Design: 1 for, 6 againstIdea: 0 for, 4 against
The thread, comment by comment
Each row is a top-level comment and its replies, in HN's order. Select a cell to open that comment on HN.
positive neutral or mixed critical about another commenter or something else the maker
What HN said
What people liked
Hexfloat support is a good choice for parsing and readability
From 1 comment
I really like the inclusion of hexfloats (beware of C++ iostream bugs, though), because they're wayyyyy easier to parse correctly than decimal floats (way faster, too). As an…
formerly_proven on HN
Interesting work in a space that needs more attention
From 1 comment
Glad to see more work in this space. You might spend a little more saying what makes your approach unique: "Use text based formats that are bloated and slow, or use binary…
mpweiher on HN
Objections
Optional behaviour in the spec, especially for NUL, will cause interoperability problems
From 4 comments
So while I like the idea of asn-like multiple encoding standards, there are some fragments in the description that make me just see potential issues: > Support for the NUL…
viraptor on HNAs a programmer who had to wrestle with like 30 formats during his career, here's one piece of non-negotiable requirement: ---------- NO. OPTIONAL. PARTS. OF. THE. STANDARD! (And…
pdimitar on HNVotes on comments are not public, so let me agree loudly: Many people will not want to use a format with implementation defined or optional behavior. That way lies pain.
tux3 on HNOptionality is a bigger problem than people realize, these special cases force “conditional pollution”, and when the optionality is implemented with exceptions, you now have to…
sitkack on HN
Too many similar formats already exist; the format adds to format creep
From 2 comments
How does this address format creep? Why is it going to be better to support all the existing formats and now this one too? Does it really add that much? The first formats filled…
spacemanmatt on HNSeriously, another one? https://xkcd.com/927/ Why was CBOR not good enough this time? Still not enough string types? Oh, indeed, CBOR doesn't have markup, whatever that means.
08-15 on HN
Built-in URL and UUID types add complexity and parsing edge cases
From 2 comments
Native support for complex types like URLs and UUIDs is a mistake. It just makes it more complicated and harder to interoperate with other formats like JSON. Look at all the…
IshKebab on HNURL parsing is a nightmare. There are lots of RFCs, but the real world is full of quirks. This will lead to edge case differences between the implementations. Also, which URI…
ysleepy on HN
No compact way to represent arrays of homogeneous records or deduplicate map keys
From 2 comments
So while I like the idea of asn-like multiple encoding standards, there are some fragments in the description that make me just see potential issues: > Support for the NUL…
viraptor on HNNot the GP but regarding no references for map keys; I can imagine that this would be an issue when representing a list of maps with uniform keys. E.g. a list of 1000 points with…
grncdr on HN
Requests
Build a compliance test tool for implementations
From 1 comment
As a programmer who had to wrestle with like 30 formats during his career, here's one piece of non-negotiable requirement: ---------- NO. OPTIONAL. PARTS. OF. THE. STANDARD! (And…
pdimitar on HN
Add a related work section and a formal grammar
From 1 comment
In a project like this I look for a "related work" section (that shows you know the context and are at least not reinventing [square] wheels and have some reason why your thing…
carapace on HN
Clarify what makes it different from existing formats like Ion, CBOR, and EDN
From 2 comments
Glad to see more work in this space. You might spend a little more saying what makes your approach unique: "Use text based formats that are bloated and slow, or use binary…
mpweiher on HNHow does this compare to Amazon Ion? https://amzn.github.io/ion-docs/
wsargent on HN
Reconsider the byte array annotation style
From 1 comment
It's weird that you use a completely different annotation style for byte arrays. Why not just use bytes = u8[10 ff 38 9a dd 00 4f 4f 91]
seanalltogether on HN
Questions
How does it compare to EDN, Transit or Fressian
From 1 comment
Are you aware of EDN, Transit or Fressian, which IMO improve a lot on the currently common approaches to encoding (JSON / YAML)? If so, how does Concise Encoding differentiate…
valw on HN
How are multi-line strings written
From 1 comment
how do you do multi line strings, the thing I don't like about YAML is there are 101 ways to do a multiline string.
evnix on HN
Does the format validate that a URL is a URL
From 1 comment
Personally I think it’s nice, though I think they’re basically syntactic sugar for a string and byte array. Does the format validate that a URL is actually a URL?
Aeolun on HN
Alternatives named
CBOR
From 2 comments
CBOR is filling the same requirements and is isomorphic to JSON.
jiehong on HNSeriously, another one? https://xkcd.com/927/ Why was CBOR not good enough this time? Still not enough string types? Oh, indeed, CBOR doesn't have markup, whatever that means.
08-15 on HN
Amazon Ion
From 1 comment
How does this compare to Amazon Ion? https://amzn.github.io/ion-docs/
wsargent on HN
EDN, Transit and Fressian
From 1 comment
Are you aware of EDN, Transit or Fressian, which IMO improve a lot on the currently common approaches to encoding (JSON / YAML)? If so, how does Concise Encoding differentiate…
valw on HN
Property lists
From 1 comment
Glad to see more work in this space. You might spend a little more saying what makes your approach unique: "Use text based formats that are bloated and slow, or use binary…
mpweiher on HN
Bencode
From 1 comment
Hmm seems like a battery packed version of bencoding but maybe someone can enlighten further?
dfischer on HN
Red language
From 1 comment
The basic premise (The friendly data format for human & machine) instantly reminded me of Red language [1], which, by the virtue of homoiconicity, is also its own data format…
9214 on HN