Oh look, Google is shipping their org chart again.<p><pre><code> > 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.
</code></pre>
According to Google themselves, this change "solves no user problems" and introduces "an explosion of verbosity."
I've always liked the simplicity of protobuf, and this change seems to add unnecessary complexity. And: "What problems are Editions solving? In short, nothing really (for end users). The introduction of Editions is the result of major Google-internal refactoring[...]"
> It’s unclear what an edition's official support lifetime will be today, although Google has suggested it might be “like 10 years.”<p>ambiguous timeline? sounds right for google.
As if I couldn’t hate protobufs any more. They go and layer on yet more complexity.<p>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.
I still don't understand why protobuf has to be in so many Go libraries. It's impossible to avoid unless you roll your own metrics, logging, maybe even mux...