Why do we feel using variable length integers in protobuf's wire format vs strings is an instant deal breaker? Isn't understanding a protocol is going to require a more documentation than just a string field name? The kind of documentation that can often be found as comments in a protocol buffer definition file?
Having written a binary serialization format that does make the choice to use strings for field identifiers on the wire (https://litevectors.org), I can still see the appeal of using integers - they're smaller and parse faster. I've used protocol buffers in several places, including in an embedded microcontroller where parsing something like JSON would have been a lift. Aside from some issues with the impact of deeply nested buffers on the stack size, protocol buffers worked brilliantly, and allowed us to keep a consistent data representation across multiple languages and platforms.
Having written a binary serialization format that does make the choice to use strings for field identifiers on the wire (https://litevectors.org), I can still see the appeal of using integers - they're smaller and parse faster. I've used protocol buffers in several places, including in an embedded microcontroller where parsing something like JSON would have been a lift. Aside from some issues with the impact of deeply nested buffers on the stack size, protocol buffers worked brilliantly, and allowed us to keep a consistent data representation across multiple languages and platforms.