4 ms·

You missed my biggest gripe: the Golang influenced decision that "zero strictly equals nil." This decision is non-idiomatic in, honestly, most languages.

• throwaway894345 4y ago
  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).
  • tommiegannert 4y ago
    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.
• FridgeSeal 4y ago
  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.
• shadowgovt 4y ago
  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.
• dilyevsky 4y ago
  That is not longer the case - they brought back optional in proto3
• yencabulator 4y ago
  What. Protocol Buffers are from 2001, Go is from 2009.