Serializing data can be crucial for maintaining fast and reliable systems. In this talk we will look at options beyond JSON and examine the pros and cons of various serialization options available in Go.
We will look at specific pitfalls when writing custom serializers when designing or choosing between flexible, fast and compact serializers. We use real life examples to examine the Go tools that are available to help out and how they can be connected up.
About Klaus
Klaus has been an avid Gopher for 8 years coming from C/C++ and assembly. Everything related to speed has his interest. He is also the host of “Go After Dark” video series on real time graphics programming in Go and author of various stream and compression packages for Go.
One format I noticed you didn’t mention in the classification chart, but still appears appealing in spite of its age, because it is self-describing while reasonably compact is ASN.1 BER, which is even included in the standard Go library. Do you have any idea why it sees so little use ?
Of course, it is not entirely streamable, but decoding can be realized while the stream progressing for all types.
I didn’t include it, since it is so rarely seen and I don’t have to much personal experience with it. As such, there is also little tooling.
I think the main reason it isn’t used more is that there is no structured types it. It has arrays and unkeyed sets, but no keyed sets/objects. For compatibility you pretty much have to do it all yourself, since there are no keys, etc. This doesn’t disqualify it, it just makes it harder to use.
As a pure binary format it is rather ineffective. A boolean is 3 bytes, same for most list/set elements.
TLDR; I don’t see any reason you would pick this for any new project. There are formats that are better at pretty much every aspect.