It makes a lot of sense for a wire format to save space by having a default value and omitting the message when the value is the default, and by standardizing on a specific default, the protobuffer protocol avoids developers having to wonder what the default is for every field.

I agree that it can be a sharp edge for the tool if you don't see it coming... It can be convenient to deserialize a protobuffer into an in-memory representation for working with it. Proto doesn't do this for you because it would be unnecessary overhead if your code can just work with the protobuffers as-is, and protobuffer errs on the side of speed.

That is not longer the case - they brought back optional in proto3

I’m not familiar with protobufs, but zero and nil are different types in Go. You can’t even compare a numeric type with a reference type (it’s a compiler error).

GP meant that you can't differentiate between the zero-value and "not present".

In proto2, strings were represented as *string in Go. In proto3, they are simply string, and "" is the default.

It’s especially awful because protobufs will incorrectly parse non-matching messages-filling in blank and mismatched fields, instead of just failing out.

Had that happen more than once, and it made for an extremely confusing situation.

What. Protocol Buffers are from 2001, Go is from 2009.