"They also didn’t want to limit the number of supported language stacks"
But that's exactly the problem with protocol buffers. In typical Google fashion, they never bothered to create support for the native language of their platform: Kotlin. And that was just the one example we encountered on a project. If your language isn't supported by protoc, then what?
Also touted was protocol buffers' "future-proofing" or resistance to version changes. We never realized this alleged benefit, and it wasn't clear how it was supposed to be delivered.
I dreaded the opacity of the format, and expected decodes to start failing in mysterious ways at some point... wasting days or weeks of my time. But I have to admit that this rarely if ever happened. In our case we were using C++ on one end and Swift on the other.
I don't get this rationale in the article: "While the size can be optimized using standard compression algorithms like gzip, compression and decompression consumes additional hardware resources." And unpacking protobufs doesn't?
Resistance to version changes in protocol buffers comes from practice and doctrine that is widespread in the user community, not entirely from the format itself. There is really only 1 point to keep in mind.
1) Never change the type or semantic meaning of a field.
Numbered fields in proto definitions obviate the need for version checks which is one of the explicitly stated motivations for the design and implementation of Protocol Buffers... With numbered fields, you never have to change the behavior of code going forward to maintain backward compatibility with older versions."
How is the format opaque ither than being a binary protocol? It has great documentation on encoding/decoding and a tool for inspecting the binary messages https://protobuf.dev/programming-guides/encoding/
No, but it makes the code a mess because you’re handling optionals for every protobuf field deref. So you’ve got error handling all over the place. It looks like go’s error handling.
They really are optional though. This is inherent in the problem if you want to support arbitrary past and future versions. You need to decide what to do when the data is missing. Open file formats are a difficult problem. [1]
I might define a different class for a validated object, so version skew only needs to be dealt with at the system edge.
Maybe you don’t actually have that problem because you can make a closed-world assumption? For example, you control all writers and aren’t saving any old-format data, like in a database that has a schema. In that case you can make fields required.
I had seen a couple of talks on Kotlin where there were representatives from Google saying not only was it supported, but was the recommended language over Java for newer services that aren’t written in cpp/python/go.
But that's exactly the problem with protocol buffers. In typical Google fashion, they never bothered to create support for the native language of their platform: Kotlin. And that was just the one example we encountered on a project. If your language isn't supported by protoc, then what?
Also touted was protocol buffers' "future-proofing" or resistance to version changes. We never realized this alleged benefit, and it wasn't clear how it was supposed to be delivered.
I dreaded the opacity of the format, and expected decodes to start failing in mysterious ways at some point... wasting days or weeks of my time. But I have to admit that this rarely if ever happened. In our case we were using C++ on one end and Swift on the other.
I don't get this rationale in the article: "While the size can be optimized using standard compression algorithms like gzip, compression and decompression consumes additional hardware resources." And unpacking protobufs doesn't?