Gobs work with the language in a way that an externally-defined, language-independent encoding cannot. At the same time, there are lessons to be learned from the existing systems.
Gobs is designed specifically for golang with several goals in mind.
- Easy to use. First, because Go has reflection, there is no need for a separate interface definition language or “protocol compiler”. The data structure itself is all the package should need to figure out how to encode and decode it. On the other hand, this approach means that gobs will never work as well with other languages, but that’s OK: gobs are unashamedly Go-centric.
- Efficiency. Textual representations, exemplified by XML and JSON, are too slow to put at the center of an efficient communications network. A binary encoding is necessary.
Gob streams must be self-describing. Each gob stream, read from the beginning, contains sufficient information that the entire stream can be parsed by an agent that knows nothing a priori about its contents. This property means that you will always be able to decode a gob stream stored in a file, even long after you’ve forgotten what data it represents.
difference with Protobuf:
- protocol buffers only work on the data type we call a struct in Go.
- Go has no
requiredkey word, making the data structure easier to maintain and more efficient. - Go has no default value. Same above
more detailed discussion here