Rob Pike: Gobs of data (2011)

1. gerbil-cbor

   1 1 0 10.0 Scheme

   Discontinued CBOR/RFC 8949 implementation for Gerbil Scheme

   I'm in the same boat. Not to mention security concerns that often crop up in (interpreted) language specific deserialization (I'm looking at you, pickle, thinly veiled `eval()`). I agree that CBOR should generally be the serialization tool of choice for self-describing data (ie. in places where you might otherwise choose JSON).

   And if your language of choice doesn't have a CBOR lib, CBOR is fairly easy to implement and writing a encoder/decoder is very fun! I recently completed my implementation for the Gerbil Scheme language last week [0].

   [0]: https://github.com/chiefnoah/gerbil-cbor

2. InfluxDB

   www.influxdata.com featured

   InfluxDB – Built for High-Performance Time Series Workloads. InfluxDB 3 OSS is now GA. Transform, enrich, and act on time series data directly in the database. Automate critical tasks and eliminate the need to move data externally. Download now.

   

3. ion-docs

   2 5 24 7.6 JavaScript

   Source for the GitHub Pages for Ion.

   

   Have you tried the superset of json from AWS?

   https://amazon-ion.github.io/ion-docs/

4. go_serialization_benchmarks

   3 8 1,593 4.6 Go

   Benchmarks of Go serialization methods

   

   Someone made a benchmark of serialization libraries in go [1], and I was surprised to see gobs is one of the slowest ones, specially for decoding. I suspect part of the reason is that the API doesn't not allow reusing decoders [2]. From my explorations it seems like both JSON [3], message-pack [4] and CBOR [5] are better alternatives.

   By the way, in Go there are a like a million JSON encoders because a lot of things in the std library are not really coded for maximum performance but more for easy of usage, it seems. Perhaps this is the right balance for certain things (ex: the http library, see [6]).

   There are also a bunch of libraries that allow you to modify a JSON file "in place", without having to fully deserialize into structs (ex: GJSON/SJSON [7] [8]). This sounds very convenient and more efficient that fully de/serializing if we just need to change the data a little.

   --

   1: https://github.com/alecthomas/go_serialization_benchmarks

   2: https://github.com/golang/go/issues/29766#issuecomment-45492...

   --

   3: https://github.com/goccy/go-json

   4: https://github.com/vmihailenco/msgpack

   5: https://github.com/fxamacker/cbor

   --

   6: https://github.com/valyala/fasthttp#faq

   --

   7: https://github.com/tidwall/gjson

   8: https://github.com/tidwall/sjson

5. go

   4 2,274 128,440 10.0 Go

   The Go programming language

   

   Someone made a benchmark of serialization libraries in go [1], and I was surprised to see gobs is one of the slowest ones, specially for decoding. I suspect part of the reason is that the API doesn't not allow reusing decoders [2]. From my explorations it seems like both JSON [3], message-pack [4] and CBOR [5] are better alternatives.

   By the way, in Go there are a like a million JSON encoders because a lot of things in the std library are not really coded for maximum performance but more for easy of usage, it seems. Perhaps this is the right balance for certain things (ex: the http library, see [6]).

   There are also a bunch of libraries that allow you to modify a JSON file "in place", without having to fully deserialize into structs (ex: GJSON/SJSON [7] [8]). This sounds very convenient and more efficient that fully de/serializing if we just need to change the data a little.

   --

   1: https://github.com/alecthomas/go_serialization_benchmarks

   2: https://github.com/golang/go/issues/29766#issuecomment-45492...

   --

   3: https://github.com/goccy/go-json

   4: https://github.com/vmihailenco/msgpack

   5: https://github.com/fxamacker/cbor

   --

   6: https://github.com/valyala/fasthttp#faq

   --

   7: https://github.com/tidwall/gjson

   8: https://github.com/tidwall/sjson

6. go-json

   5 24 3,432 4.9 Go

   Fast JSON encoder/decoder compatible with encoding/json for Go

   

   Someone made a benchmark of serialization libraries in go [1], and I was surprised to see gobs is one of the slowest ones, specially for decoding. I suspect part of the reason is that the API doesn't not allow reusing decoders [2]. From my explorations it seems like both JSON [3], message-pack [4] and CBOR [5] are better alternatives.

   By the way, in Go there are a like a million JSON encoders because a lot of things in the std library are not really coded for maximum performance but more for easy of usage, it seems. Perhaps this is the right balance for certain things (ex: the http library, see [6]).

   There are also a bunch of libraries that allow you to modify a JSON file "in place", without having to fully deserialize into structs (ex: GJSON/SJSON [7] [8]). This sounds very convenient and more efficient that fully de/serializing if we just need to change the data a little.

   --

   1: https://github.com/alecthomas/go_serialization_benchmarks

   2: https://github.com/golang/go/issues/29766#issuecomment-45492...

   --

   3: https://github.com/goccy/go-json

   4: https://github.com/vmihailenco/msgpack

   5: https://github.com/fxamacker/cbor

   --

   6: https://github.com/valyala/fasthttp#faq

   --

   7: https://github.com/tidwall/gjson

   8: https://github.com/tidwall/sjson

7. msgpack

   6 3 2,490 4.2 Go

   msgpack.org[Go] MessagePack encoding for Golang (by vmihailenco)

   

   Someone made a benchmark of serialization libraries in go [1], and I was surprised to see gobs is one of the slowest ones, specially for decoding. I suspect part of the reason is that the API doesn't not allow reusing decoders [2]. From my explorations it seems like both JSON [3], message-pack [4] and CBOR [5] are better alternatives.

   By the way, in Go there are a like a million JSON encoders because a lot of things in the std library are not really coded for maximum performance but more for easy of usage, it seems. Perhaps this is the right balance for certain things (ex: the http library, see [6]).

   There are also a bunch of libraries that allow you to modify a JSON file "in place", without having to fully deserialize into structs (ex: GJSON/SJSON [7] [8]). This sounds very convenient and more efficient that fully de/serializing if we just need to change the data a little.

   --

   1: https://github.com/alecthomas/go_serialization_benchmarks

   2: https://github.com/golang/go/issues/29766#issuecomment-45492...

   --

   3: https://github.com/goccy/go-json

   4: https://github.com/vmihailenco/msgpack

   5: https://github.com/fxamacker/cbor

   --

   6: https://github.com/valyala/fasthttp#faq

   --

   7: https://github.com/tidwall/gjson

   8: https://github.com/tidwall/sjson

8. cbor

   7 5 886 8.8 Go

   CBOR codec (RFC 8949, RFC 8742) with CBOR tags, Go struct tag options (toarray, keyasint, omitempty, omitzero), float64/32/16, big.Int, and fuzz tested.

   

   Someone made a benchmark of serialization libraries in go [1], and I was surprised to see gobs is one of the slowest ones, specially for decoding. I suspect part of the reason is that the API doesn't not allow reusing decoders [2]. From my explorations it seems like both JSON [3], message-pack [4] and CBOR [5] are better alternatives.

   By the way, in Go there are a like a million JSON encoders because a lot of things in the std library are not really coded for maximum performance but more for easy of usage, it seems. Perhaps this is the right balance for certain things (ex: the http library, see [6]).

   There are also a bunch of libraries that allow you to modify a JSON file "in place", without having to fully deserialize into structs (ex: GJSON/SJSON [7] [8]). This sounds very convenient and more efficient that fully de/serializing if we just need to change the data a little.

   --

   1: https://github.com/alecthomas/go_serialization_benchmarks

   2: https://github.com/golang/go/issues/29766#issuecomment-45492...

   --

   3: https://github.com/goccy/go-json

   4: https://github.com/vmihailenco/msgpack

   5: https://github.com/fxamacker/cbor

   --

   6: https://github.com/valyala/fasthttp#faq

   --

   7: https://github.com/tidwall/gjson

   8: https://github.com/tidwall/sjson

9. SaaSHub

   www.saashub.com featured

   SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives

   

10. fasthttp

    8 39 22,652 8.9 Go

    Fast HTTP package for Go. Tuned for high performance. Zero memory allocations in hot paths. Up to 10x faster than net/http

    

    Someone made a benchmark of serialization libraries in go [1], and I was surprised to see gobs is one of the slowest ones, specially for decoding. I suspect part of the reason is that the API doesn't not allow reusing decoders [2]. From my explorations it seems like both JSON [3], message-pack [4] and CBOR [5] are better alternatives.

    By the way, in Go there are a like a million JSON encoders because a lot of things in the std library are not really coded for maximum performance but more for easy of usage, it seems. Perhaps this is the right balance for certain things (ex: the http library, see [6]).

    There are also a bunch of libraries that allow you to modify a JSON file "in place", without having to fully deserialize into structs (ex: GJSON/SJSON [7] [8]). This sounds very convenient and more efficient that fully de/serializing if we just need to change the data a little.

    --

    1: https://github.com/alecthomas/go_serialization_benchmarks

    2: https://github.com/golang/go/issues/29766#issuecomment-45492...

    --

    3: https://github.com/goccy/go-json

    4: https://github.com/vmihailenco/msgpack

    5: https://github.com/fxamacker/cbor

    --

    6: https://github.com/valyala/fasthttp#faq

    --

    7: https://github.com/tidwall/gjson

    8: https://github.com/tidwall/sjson

11. GJSON

    9 39 14,987 5.9 Go

    Get JSON values quickly - JSON parser for Go

    

    Someone made a benchmark of serialization libraries in go [1], and I was surprised to see gobs is one of the slowest ones, specially for decoding. I suspect part of the reason is that the API doesn't not allow reusing decoders [2]. From my explorations it seems like both JSON [3], message-pack [4] and CBOR [5] are better alternatives.

    By the way, in Go there are a like a million JSON encoders because a lot of things in the std library are not really coded for maximum performance but more for easy of usage, it seems. Perhaps this is the right balance for certain things (ex: the http library, see [6]).

    There are also a bunch of libraries that allow you to modify a JSON file "in place", without having to fully deserialize into structs (ex: GJSON/SJSON [7] [8]). This sounds very convenient and more efficient that fully de/serializing if we just need to change the data a little.

    --

    1: https://github.com/alecthomas/go_serialization_benchmarks

    2: https://github.com/golang/go/issues/29766#issuecomment-45492...

    --

    3: https://github.com/goccy/go-json

    4: https://github.com/vmihailenco/msgpack

    5: https://github.com/fxamacker/cbor

    --

    6: https://github.com/valyala/fasthttp#faq

    --

    7: https://github.com/tidwall/gjson

    8: https://github.com/tidwall/sjson

12. sjson

    10 7 2,535 0.0 Go

    Set JSON values very quickly in Go

    

    Someone made a benchmark of serialization libraries in go [1], and I was surprised to see gobs is one of the slowest ones, specially for decoding. I suspect part of the reason is that the API doesn't not allow reusing decoders [2]. From my explorations it seems like both JSON [3], message-pack [4] and CBOR [5] are better alternatives.

    By the way, in Go there are a like a million JSON encoders because a lot of things in the std library are not really coded for maximum performance but more for easy of usage, it seems. Perhaps this is the right balance for certain things (ex: the http library, see [6]).

    There are also a bunch of libraries that allow you to modify a JSON file "in place", without having to fully deserialize into structs (ex: GJSON/SJSON [7] [8]). This sounds very convenient and more efficient that fully de/serializing if we just need to change the data a little.

    --

    1: https://github.com/alecthomas/go_serialization_benchmarks

    2: https://github.com/golang/go/issues/29766#issuecomment-45492...

    --

    3: https://github.com/goccy/go-json

    4: https://github.com/vmihailenco/msgpack

    5: https://github.com/fxamacker/cbor

    --

    6: https://github.com/valyala/fasthttp#faq

    --

    7: https://github.com/tidwall/gjson

    8: https://github.com/tidwall/sjson

Suggest a related project