Hacker News Reader

Comment by sa46 | Hacker News Reader

When I was at Google around 2016, there was a significant push to convince folks that the proto3 implicit presence was superior to explicit presence.

Is there a design doc with the rationale for switching back to explicit presence for Edition 2023?

The closest docs I've found are https://buf.build/blog/protobuf-editions-are-here and https://github.com/protocolbuffers/protobuf/tree/main/docs/d....

View on HN

Best bet is likely https://github.com/protocolbuffers/protobuf/blob/main/docs/f..., which predates editions.

I was only there for the debate you mentioned and not there for the reversal, so I dunno.

I wasn't there for the debate, but was there for the reversal. I don't remember there being anything explicitly said about it. The only thing I can think of is that I know of some important projects that couldn't migrate to proto3 because of this implicit field issue. So some people were still writing new code with proto2.

And... most of the important projects are still using proto2 and there is no realistic way to do interop between those two formats. IIRC, you cannot use proto2 enum in proto3 for some obscure technical reason! This creates a backsliding issue; you cannot migrate old protos with thousands of different messages, fields and enums where new proto2 messages to use them are added everyday.

This is an important distinction from the proto1->proto2 migration, which was in a much better compatibility situation yet still took years to complete. AFAIK, this is the main reason why the proto team decided to create a superset approach (edition) so migration can be handled as a flag at each message level.

Reply on news.ycombinator.com