Concise Encoding

Languages and libraries

data serialization format

SHOW HN2020

78points
46comments
#806of 3,028 in 2020
Top 27%of 2020 by points

How HN took it

CuriousMostly questions and neutral comments

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 HN
    • 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
    • Votes 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 HN
    • Optionality 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 HN
    • Seriously, 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 HN
    • URL 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 HN
    • Not 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 HN
    • How 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 HN
    • Seriously, 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

Category, keywords, summaries and labels on this page were made by AI (Thread Reader v2) and not checked by hand. Each point links to the comments it came from.

Add a badge to your READMEShown on HackerShow
[![Shown on HackerShow](https://hackershow.org/badge.svg)](https://hackershow.org/show/24676774)