> What problems are Editions solving?
>
> In short, nothing really (for end users). The introduction of Editions
> is the result of major Google-internal refactoring of how protoc and its
> plugin architecture implements and observes feature checks when generating
> code. This isn’t intended to force breaking changes to existing projects,
> nor is it designed to impact any of the existing encodings.
>
> It should be a boring change that gives plugin maintainers finer-grained
> control over how future versions of their Protobuf runtimes behave,
> improvements are made, and new features are introduced. Having said that,
> it’s impossible to ignore the explosion of verbosity that Editions has
> introduced to the project as a side-effect of this level of available control.
According to Google themselves, this change "solves no user problems" and introduces "an explosion of verbosity."> This means your existing proto3 projects can now use default field values and extensions.
proto3 not having required and default values was a big source of complaints, so supporting these indefinitely into the future with feature flags instead of having to be stuck forever on proto2 has to be a welcome change for a subset of users, at the very least.
(BTW, this isn't "shipping their org chart.")
Though, the closer it is to a true a "law", then the closer GP's comment approaches a tautology.
Is the author just annoyed that Buf now has to put in the work to support editions?
ambiguous timeline? sounds right for google.
Thanks Sundar for great org incentive structure!
These sorts of things need to be as simple as humanly possibly and get out of your way so you can actually do some programming. Instead protobufs are the opposite. Full of backwards compat issues, footguns, and needless complexity that make them an absolute horror to work with.
Lord knows how much energy we are wasting turning binary data into human readable text that no human will ever look at before it's parsed back into binary.
Now just wait for golang packages that have conflicting editions requirements!
They were developed as a microservice high-performance lang, compiler, and serialization protocol in the same meetings.
Do wake me when they get around to adding the 'high performance' lang part though. Wild how all this ecosystem junk originates from a few early Googlers' fear of learning beautiful C.