Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Segmentio/encoding: optimized drop-in replacement for Go's encoding/JSON package

github.com

Post reply on HN
Print view View original

1–10 of 19 posts

Re: Segmentio/encoding: optimized drop-in replacement for Go's encoding/JSON package

#3

Post by q3k »

soamv wrote: post #2

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.

Re: Segmentio/encoding: optimized drop-in replacement for Go's encoding/JSON package

#5

Post by pelletier »

ilovecaching wrote: post #4
soamv wrote: post #2

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

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).

Re: Segmentio/encoding: optimized drop-in replacement for Go's encoding/JSON package

#7

Post by bscphil »

One of the typical arguments in favor of small base languages is that frequently the best package will be written by a third party and become the "default", making the language bloated. For example, everyone uses Requests in Python instead of the built-in alternative. On the other hand, I think a big advantage of batteries-included languages that they define a standard implementation that other libraries can copy. Because there's an official JSON package for Go, everyone already knows how to use this new one, since it's a drop-in replacement. Obviously this won't happen in all cases, but when it does it feels really nice.

Re: Segmentio/encoding: optimized drop-in replacement for Go's encoding/JSON package

#8

Post by OzzyB »

My problem with serialization in Go isn't so much speed but marshalling/unmarshalling pain.

I've been using these packages with some success:

https://github.com/tidwall/sjson

https://github.com/tidwall/gjson

Not knocking this pkg, just thought I'd share xD

Re: Segmentio/encoding: optimized drop-in replacement for Go's encoding/JSON package

#9

Post by kibwen »

bscphil wrote: post #7

One of the typical arguments in favor of small base languages is that frequently the best package will be written by a third party and become the "default", making the language bloated. For example, everyone uses Requests in Python instead of the built-in alternative. On the other hand, I think a big advantage of batteries-included languages that they define a standard implementation that other libraries can copy. Be…

> everyone uses Requests in Python

I love Requests, but this statement overreaches. All of my Python these days is simple scripting, and in those simple cases the hassle of adding a dependency outweighs the utility that Requests provides over the standard library. And I'd say Requests is even a special case here in that it's widely known and acknowledged; while I wager you can find superior third-party replacements to the Python standard library if you look for them, the fact that you don't need to look for them at all (and audit them, ideally!) is what makes a batteries-included language so convenient even in the presence of a sub-par stdlib.

Post reply on HN