Hopefully this is good news. The old Protobuf package had ossified, with lots of ergonomic issues that the maintainers seemed uninterested in addressing. One p

Hopefully this is good news. The old Protobuf package had ossified, with lots of ergonomic issues that the maintainers seemed uninterested in addressing. One perennial annoyance is how awkwardly some Protobuf stuff ends up being represented in Go. For example, "oneof" types: message Event { oneof payload { Create create = 1; Delete delete = 2; } } message Create { string id = 1; } message Delete { string version = 1; } You get these messy types (I've elided most of the yucky marshaling-related stuff): type Event struct { Payload isEvent_Payload `protobuf_oneof:"item"` } type isEvent_Payload interface { isEvent_Payload() MarshalTo([]byte) (int, error) Size() int } type Event_Create struct { Create *Create `protobuf:"bytes,1,opt,name=create,proto3,oneof"` } type 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 https://github.com/gogo/protobuf/issues/218