Adam, I understand there is no *current* plan to deprecate proto2. But is it really expected to be supported forever?
If that's the case, I suppose the only reason to choose proto3 over proto2 (if you happen to want the features and semantics of proto2) might be that not all languages/runtimes have support for proto2. Though I thought this was a short/medium-term issue. If all languages/runtimes eventually support both, it seems like a strange decision to continue supporting both indefinitely. ---- *Josh Humphries* [email protected] On Tue, Dec 19, 2017 at 2:23 PM, Adam Cozzette <[email protected]> wrote: > Actually we have no plans to deprecate proto2 and we are still actively > developing it, so you can really choose either one without having to worry > about support going away. > > On Sat, Dec 16, 2017 at 11:42 AM, Josh Humphries <[email protected]> > wrote: > >> 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. >> > > -- 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.
