I think proto3 was intended to be simpler -- an evolution of protobuf in a direction that is more refined and elides superfluous features. Eventually (though not likely any time soon), support for proto2 will go away.
The main omission in proto3 that I personally felt strongly about was the lack of preserving unknown fields. But that functionality has been restored for many languages/runtimes in 3.5 (and coming soon, hopefully, for Go and the others). All of the other omissions in proto3 have alternate solutions/work-arounds that aren't baked into the language (like wrapper types and Any), which shows that these features didn't truly need to be language features to begin with. So it allows the language itself to remain simple, which means libraries/tooling are simpler to build on top. So a big advantage of proto3 is simplicity (and for some languages/runtimes, that will translate into improved performance). And another advantage is future compatibility (since, in all likelihood, proto2 will eventually go away.) If creating new files, it makes sense to use proto3. If you already have a corpus of proto2 files, a reasonable migration path forward is to start evolving them to proto3 (or, if the languages/runtimes you use don't yet preserve unrecognized fields, wait for that functionality to be fully implemented everywhere and then start evolving). - Make required fields optional. Required fields have always been dangerous. If a field is required in your protocol, it can be enforced in application code instead of in the de-serialization logic of the protobuf runtime. - Use Any instead of extensions. An extension range can generally be replaced with a repeated Any field. Extensions with scalar types will have to be "boxed" into single-field messages. - Use wrapper types for scalar fields where absence must be distinguishable from zero. - Usages of default values can be changed to use wrapper types and application logic that decides non-zero values to use when the field is not present. - Groups should be replaced with nested messages. Once a file is no longer using any proto2 features, it can be changed to proto3 syntax. Unfortunately, there is not yet a way to incrementally move to proto3. Once you change the syntax of the file, the generated code will change, and all clients of that generated code must be changed atomically in order to compile (at least for languages/runtimes where generated code for the two syntaxes is materially different/incompatible). I would hope that this is something that will be addressed in future versions of protobuf, to facilitate migrations away from proto2. ---- *Josh Humphries* [email protected] On Sat, Dec 16, 2017 at 2:17 PM, ajcurtis84 <[email protected]> wrote: > Thank you everyone for all the great input! > > Based on this discussion, what is the advantage of using proto3? It > appears that proto2 is more feature rich. JSON isn't a compelling reason.... > > Thanks > > -- > You received this message because you are subscribed to the Google Groups > "Protocol Buffers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/protobuf. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/protobuf. For more options, visit https://groups.google.com/d/optout.
