[cousin_it]

It helps that we have one big source control repository for the whole company, which runs many custom hooks that can block changes from being committed. For example, if I try to add a field whose id is lower than the next available id specified in the .proto file, my change won't commit. Same if I try to remove a field that's still used by someone else and my change breaks their build.

More generally, I think RPC interfaces need to be forward-compatible by design. If you have two binaries that are released on different schedules, and the API between them is fully rigid, how do you ever change it? Version the whole API, for a change that adds one boolean feature flag to one struct somewhere? Write a converter for fifty existing fields every time you add a new field, leading to O(n^2) programmer work over time? Come on.

Even more generally, I think static types are a great idea, but they work best locally. Communication over longer distances (in space and time) requires a different set of tradeoffs. There's a reason why people design network protocols and file formats with open-ended forward compatibility in mind. RPCs are kind of a middle ground, and I've found that the tradeoffs in Protocol Buffers work pretty well. YMMV.