protobuf

Event_Delete struct { Delete *Delete `protobuf:"bytes,1,opt,name=delete,proto3,oneof"` } There are multiple problems here. One: Why the extra struct? For example, to create a single event, you have to do: Event{ Payload: &Event_Create{ Create: &Create{ID: "123"}, }, }, ...instead of just: Event{ Payload: &Create{ID: "123"}, }, Secondly, isEvent_Payload is private! So given a Create or an Delete, you can't store it in a single variable: func nextEvent() isEvent_Payload { // <-- not possible if something { return &Create{...} } else { return &Delete{...} } } The reason for this appears to be so that the generated serialization can be very dumb and not rely on type switches. But I don't buy that this is how it has to be. There are other issues. Overall, the whole package seems designed from the bottom up for machines (mumbles possibly also by machines), not humans.The upshot is that using Protobuf types as "first-class" types — meaning the types you actually use internally in the meat of your app, as opposed to in the controller glue that lives in your API and mediates between the API and the internals — feels super messy. As an aside, anyone know what issues this paragraph refers to? The google.golang.org/protobuf/encoding/protojson package converts protocol buffer messages to and from JSON using the canonical JSON mapping, and fixes a number of issues with the old jsonpb package that were difficult to change without causing problems for existing users. Did they finally fix the zero value problem with jsonpb.go [1]? [1] https://github.com/gogo/protobuf/issues/218

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...

ngs like better date/time support). The Gogo team (understandably) doesn't want to diverge too far from the mainline, but that means open issues are stagnating while the PRs in the upstream Google project are stagnating. These issues of course then also leak into related projects that extend Protobuf, such as the Go gRPC gateway, which implements a REST proxy on top of gRPC. Since the JSON mapping is so lacking, the JSON data you get out isn't quite idiomatic JSON, which makes the gateway pretty much useless for a lot of applications. (Note: It's been about 6 months since we tried to use it and had to give up, it may have improved since.) We also ended up forking the official JSON marshal code to work around the various issues with it. Other projects such as CockroachDB also do this. [1] https://github.com/gogo/protobuf