Hacker News Reader

Comment by soamv | Hacker News Reader

Looks neat, why not try to upstream it to the Go standard library if it's fully compatible?

Replacing a commonly used package like this likely wouldn't be without accidental compatibility breakage (in some edge cases), and as such I appreciate it not silently becoming the new default and potentially breaking software or corrupting data. This is especially true as JSON-the-standard (RFC7159) is horribly underspecified and as such it's difficult to even use some sort of acceptance suite to declare a replacement as suitable.

Go's standard encoding/json isn't great (for many reasons...), but it's definitely in the Good Enough category, and as such IMO falls under "if it ain't broken don't fix it" umbrella.

> This is especially true as JSON-the-standard (RFC7159) is horribly underspecified

Normally.. you would hope that the great test system built in to go would benefit stdlib upgrades like this and allow you do them more easily and with greater confidence.. but if what you're implementing suffers from this, then you pretty much stuck locking yourself into specific implementations rather than general specifications.

> but it's definitely in the Good Enough category

"Two steps forward, one step back" sums up how I feel about Go. It's still my favorite user-mode language, though.

Maybe there are ideas that can be used without changing the API surface at all? I don't think grandparent is proposing the Go developers just drop the thing in as-is without any evaluation of fitness or backwards compatibility. Part of the significance of this work is that (they claim) it is API-compatible with the stdlib version (modulo error messages, which can be addressed).

Edit: Then again, the authors advocate mildly against upstreaming it:

> For these reasons, we also don't believe that this code should be ported upsteam to the standard encoding/json package.

https://github.com/segmentio/encoding/tree/master/json#trade...

Seconded, also an explanation of why it's faster on the landing page.

Tradeoffs are at https://github.com/segmentio/encoding/tree/master/json#trade.... Maybe we should move that upfront (or at least link to it for discovery).

That's just a file list on mobile. It's better to link to the README itself: https://github.com/segmentio/encoding/blob/master/json/READM...

Ah that answers it, thanks for posting that.

Reply on news.ycombinator.com