protobuf can certainly be type safe, but "protobuf" means many things, which is confusing. My understanding is that type safety comes in the form of generated clients/servers.

> That is projected upon it by people who do not understand it.

This is the the most Googley response possible. If it's so hard to understand, maybe Google should have done a better job of explaining it?

One peer has no reason to believe that the other is using compatible generated code. I can encode AreCatsCuteRequest and you can decode NukeRussiaRequest. There is no safety in it, anywhere. Confusion about with whom you are communicating has caused real, notorious outages, even at Google.

Isn't this much of the point of gRPC? To generate clients/servers so that sending the wrong request to the wrong endpoint is much more difficult and inconvenient?

This property doesn't seem unique to protobuf nor does it seem relevant to type safety. If you're referring to protobuf's binary encoding as being problematic due to field numbers and default values, then sure, I agree that's a weakness, but again that's not what most people refer to when taking about type safety. It's perfectly reasonable to use protobuf as an IDL and not as an encoding.

> Confusion about with whom you are communicating has caused real, notorious outages, even at Google.

What does this have to do with type safety? This is authentication. mTLS and to a lesser extent TLS practically solve this.