ffjson

Languages and libraries

serialization library

SHOW HN2014

83points
35comments
#352of 2,272 in 2014
Top 16%of 2014 by points

How HN took it

CuriousMostly questions and neutral comments

1 positive, 4 neutral or asking, 0 mixed, 3 critical, out of 8 comments about the project. Thread score -0.15.

Execution: 0 for, 2 againstIdea: 1 for, 0 againstPerformance: 0 for, 1 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

  • Generating schema-specific code is faster than generic code

    From 1 comment
    • As someone who has been working on parsing/serialization for many years, I can absolutely confirm that generating schema-specific code will beat generic code almost every time.…
      haberman on HN

Objections

  • Code generation adds a compile step and is less convenient

    From 2 comments
    • As someone who has been working on parsing/serialization for many years, I can absolutely confirm that generating schema-specific code will beat generic code almost every time.…
      haberman on HN
    • Nice hack (in the hacker sense), but not exactly convenient.
      alecthomas on HN
  • Generated code tooling should not need reflection

    From 1 comment
    • If anything, that would be an indication that the tooling is nowhere near good enough. Any reflection should be doable entirely with data the compiler has anyway.
      lucian1900 on HN

Requests

  • Optionally emit key-sorted canonical JSON

    From 1 comment
    • Good stuff, there. Feature request: optionally emit canonicalized (key-sorted) JSON.
      otterley on HN

Questions

  • Whether reflection-based approaches are needed at all

    From 2 comments
    • The implementation of this is pretty interesting, in that it generates code that imports your code, compiles it, and then uses reflection to generate the serialization code. And…
      hannibalhorn on HN
    • If anything, that would be an indication that the tooling is nowhere near good enough. Any reflection should be doable entirely with data the compiler has anyway.
      lucian1900 on HN

Alternatives named

  • encoding/json with reflection

    From 1 comment
    • This is a good example of why everyone should avoid using reflect package as much as possible. I use reflect for quick development and then remove it before production roll out.
      knodi on HN
  • Cap'n Proto

    From 1 comment
    • As someone who has been working on parsing/serialization for many years, I can absolutely confirm that generating schema-specific code will beat generic code almost every time.…
      haberman on HN
  • Rust serialize macros

    From 1 comment
    • > The article discovers an important tradeoff: speed vs. convenience. Generated code is faster but less convenient, because it adds steps to your compile. Rust's approach to…
      pcwalton on HN
  • fatherhood

    From 1 comment
    • I've made a library this weekend that doesn't need code generation to achieve 2x improvement[1] over the standard library. While the OP only implemented the encoding part, I only…
      AYBABTME 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/7501891)