Protobuf Editions are here: don't panic

[jujube3]

Oh look, Google is shipping their org chart again.

  > 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."

[comex]

This blog post wasn’t written by Google themselves, but by Buf, a confusingly-named startup that makes their own protobuf implementation.

[oefrha]

As a sibling has already pointed out, this blog post has nothing to do with “Google themselves”. In addition, “nothing really for end users” is obviously bullshit and inconsistent with what the post says itself, e.g.

> 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.

[zeroxfe]

I don't understand why this is a problem. It's not uncommon to see multi-decade old systems refactored for extensibility and maintainability every once in a while. What worked when it was initially designed won't work forever, and it's hard to make users lives better if the maintainers can't make their own lives better.

(BTW, this isn't "shipping their org chart.")

[hot_gril]

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[...]"

[hot_gril]

Thinking about this more, this looks overly dismissive. Seems Google wants to be very explicit about future syntax and allow users to mix in different features. I don't think it's worthwhile, but it's doing something.

Is the author just annoyed that Buf now has to put in the work to support editions?

[hehdhdjehehegwv]

Design by promo.

[tb303]

> It’s unclear what an edition's official support lifetime will be today, although Google has suggested it might be “like 10 years.”

ambiguous timeline? sounds right for google.

[VHRanger]

The timeline depends on when the project will stop being useful to generate promotions.

Thanks Sundar for great org incentive structure!

[rco8786]

As if I couldn’t hate protobufs any more. They go and layer on yet more complexity.

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.

[drunner]

Do you have a preferred message protocol?

[candiddevmike]

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...

[jsheard]

Even if protobuf isn't your preferred serializer, having any tight binary format be the standard across the ecosystem is miles better than everything slinging JSON around.

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.

[TillE]

It's simple, lightweight, safe serialization. If you need to convert data structures to bytes, you're going to use protobuf or something comparable.

[choppaface]

golang is a Google technology, so protobuf is going to be there, right? Moreover golang is compiled and protobuf interoperates best with compiled languages.

Now just wait for golang packages that have conflicting editions requirements!

[b33j0r]

Because the same group in google developed both, indeed.

They were developed as a microservice high-performance lang, compiler, and serialization protocol in the same meetings.

[beeboobaa3]

Because it's useful? What do you propose instead?

[perezd]

Google is days away from making Protobuf Editions GA. Never heard of it? Read on.

[orf]

What’s the meaning behind this comment?