protobuf

ithout breakage. In Rust or C++, this would presumably have been accomplished with an equality trait, so that the new struct could be made comparable with ==. The third one, about breaking reflect.DeepEqual(), also reveals how the lack of trait support at the language level exposes cracks in the language. When a user is forced to use a blunt tool such as DeepEqual(), which disconnects the equality code from the underlying type being used, then this is what you get. That said, I'm not sure why Protobuf can't optionally generate equality methods for the types it generates in the first place, which is something Gogo can do [1]. Go is a great language, but it's things like this that give me Rust envy. [1] https://github.com/gogo/protobuf/blob/master/plugin/equal/eq...

produces highly unidiomatic Go. "oneof" is yet again an offender here. The gogoprotobuf [2] project tries to fix some of go-grpc's deficiencies, but it's still not sufficient. Ideally you should be able to use the Proto structs directly, but our biggest gRPC project we basically gave up here, and decided to limit Proto usage to the server layer, with a translation layer in between that translates all the Proto structs to/from native structs. That keeps things clean, but it's pretty exhausting work, which lots of type switches (which are hampered by Go's lack of switch exhaustiveness checking; we use BurntSushi's go-sumtype [3] a lot, but I don't think it can work for Proto structs, as it requires that a struct also implements an interface). 3. Proto3 has very limited support for expressing "free-form" data. By this I mean if you need to express a Protobuf field that contains a structured set of data such as {"foo": {"bar": 42}}. For this, you have the extension google.protobuf.Value [4], which supports some basic primitives, but not all (no timestamps, for example) and cannot be used to serialize actual gRPC messages; you can't serialize {"foo": MyProtoMessage{...}}. Free-form structured data is important for systems that accept foreign data where the schema isn't known; for example, a system that indexes analytics data. From what I can tell, though, Twirp doesn't "disrupt" gRPC as much as I'd like, since it appears to rely on the existing JSON mapping. [1] https://github.com/gogo/protobuf/issues/218 [2] https://github.com/gogo/protobuf [3] https://github.com/BurntSushi/go-sumtype [4] https://developers.google.com/protocol-buffers/docs/referenc...