Thanks for your quick response Adam! Regards!
On Tuesday, January 21, 2020 at 3:05:22 PM UTC-3, Adam Cozzette wrote: > > Right, we are still maintaining both proto2 and proto3 and plan to keep > supporting both flavors indefinitely. > > On Tue, Jan 21, 2020 at 4:09 AM Luciano Perezzini <[email protected] > <javascript:>> wrote: > >> This is still true, Adam? Google would not deprecate Proto2, and Proto2 >> and Proto3 are just different flavors of Protocol Buffers? Me and my team >> are about to start a brand new project using Protocol Buffers and the lack >> of missing value check properties in Proto3 is a BIG concern. >> >> Thanks in advance, and I wait for your response. >> >> Regards! >> >> On Tuesday, December 19, 2017 at 5:59:44 PM UTC-3, Adam Cozzette wrote: >>> >>> Yes, we are planning on supporting proto2 pretty much forever. Within >>> Google we have a huge amount of code using proto2 and for the most part >>> we're not attempting to migrate existing code to proto3. Language support >>> is one reason to go with proto3, but it's also simpler and more convenient >>> for working with JSON. >>> >>> On Tue, Dec 19, 2017 at 12:13 PM, Josh Humphries <[email protected]> >>> wrote: >>> >>>> 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] <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/protobuf/3e078cd3-ba3f-4ab0-a9a4-e8852f502045%40googlegroups.com >> >> <https://groups.google.com/d/msgid/protobuf/3e078cd3-ba3f-4ab0-a9a4-e8852f502045%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/protobuf/a4eb1b0d-e9c2-48e2-a807-40129db18228%40googlegroups.com.
