For me the appeal of protobuf is the wire-format forward-backward compatibility.
It's hard enough to not break logical compatibility, so I appreciate not having to think too hard about wire compat. You can of course solve the same thing with JSON, but, well, YOU have to solve it.
(Also worth noting, there are a lot of things I don't like about the grpc ecosystem so I don't actually use it that much. But this is one of the pieces I really like a lot).
Arguably JSON doesn't have this problem at all since it encodes the field names too. The only thing it doesn't handle is field renames, but I mean, come on, you know you can't rename a field in public API anyways :)
Many JSON parsers allow to store extra fields in a separate dictionary/map, and certainly the format allows for it too, so I'm not sure what makes you say that statically typed languages are at a disadvantage here
> You can of course solve the same thing with JSON, but, well, YOU have to solve it.
There is not a single well established convention across all languages/impls. The default behavior in many languages if a field is missing is to either panic, or replace it with a null pointer (which will just panic later, most likely).
It's hard enough to not break logical compatibility, so I appreciate not having to think too hard about wire compat. You can of course solve the same thing with JSON, but, well, YOU have to solve it.
(Also worth noting, there are a lot of things I don't like about the grpc ecosystem so I don't actually use it that much. But this is one of the pieces I really like a lot).