> 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?
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.
Which is even more crazy then missing parts have default value, when you consider how that behaves in some cases of mismatching schemas (it also can introduce annoying limitations when trying to create idiomatic libraries in some languages, especially such with "type-safety").
And then add in some of the "automatic type conversions it does".
And to top if of some edge cases tend to very often diverge in implementations of different languages, no matter what the original intention was.
And the result is uh, just uh, very very uh.
I understand why google uses them, it fits them. It probably a good idea given google scale problems, company and team structure and "skill level" of each member.
But that doesn't mean it's a good fit for everyone.