Community Fork: Basekick-Labs/msgpack — actively maintaining and improving

[xe-nvdk]

Hi @vmihailenco,

First, thank you for building and maintaining msgpack-go — it's been a fantastic library and we've relied on it in production for high-throughput workloads processing millions of records per second.

We noticed the last release was ~3 years ago and there are several open issues that affect our use case. We've decided to create a community fork at Basekick-Labs/msgpack where we plan to actively maintain and improve the library.

What we're working on

Bug fixes (from your open issues):

• int64 aren't properly decoded #379 — int64 not properly decoded when source was float64
• Memory is not secure and may be vulnerable to attacks #376 — Memory safety in decodeSlice allocation
• Types with pointer receivers that are not pointers cause do not encode #374 — Types with pointer receivers don't encode
• reflect.Value.SetString using unaddressable value on concrete values contained within any structures #373 — SetString panic on nested any structures
• Can encode a map[int][whatever type], but cannot decode into the any type. Get invalid code=1 decoding string/bytes length, only in v5, works in v4 #372 — map[int] regression from v4 → v5
• omitempty unexpectedly omits a member when the member is a struct with a non-zero unexported member #378 — omitempty with unexported fields

Performance optimizations:

• Zero-allocation byte-slice reader for Unmarshal (bypass bytes.NewReader + bufio.NewReader)
• Fast path for *interface{} in Decode() type-switch
• Buffer pooling in Marshal()
• Direct encode paths for map[string]interface{} and []interface{}

Our full roadmap: Basekick-Labs#8

Contributing back

We're happy to contribute fixes back upstream as PRs if you're interested. If you'd prefer to keep the upstream as-is, that's completely fine — we'll maintain the fork independently.

Thanks again for the great foundation!