Protobuf Editions are here: don't panic

https://buf.build/blog/protobuf-editions-are-here

by perezd • 2 years ago

31 55 2 years ago

buf.build

perezd3• 2 years ago

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

orf• 2 years ago

What’s the meaning behind this comment?

perezd3• 2 years ago

Many folks don't know about what Protobuf Editions are, and it's about to be generally available. I was encouraging people to read the article :)

beeboobaa32• 2 years ago

looks like an LLM spambot

tb303• 2 years ago

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.

VHRanger3• 2 years ago

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

Thanks Sundar for great org incentive structure!

candiddevmike• 2 years ago

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

TillE2• 2 years ago

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

jsheard• 2 years ago

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.

hot_gril9• 2 years ago

Performance aside, it's also really nice how a protobuf spec tells you what data structure to expect ahead of time for an API.

wbl• 2 years ago

XDR was already a core part of NFS. And then there was a DEC alternative also.

b33j0r2• 2 years ago

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.

jsnell2• 2 years ago

Where are you getting this nonsense from, and if you're just speculating, why are you stating it with such confidence as a fact? Protobufs predate Go by more than half a decade, and there is no overlap between the authors.

intelVISA• 2 years ago

You WILL accept The One Right Way to write code and serialize data! -rob pike

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.

beeboobaa32• 2 years ago

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

xyst• 2 years ago

Smoke signals

choppaface• 2 years ago

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!

hot_gril9• 2 years ago

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

hehdhdjehehegwv• 2 years ago

Design by promo.

riwsky• 2 years ago

Promobuf

hot_gril9• 2 years ago

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?

rco87862• 2 years ago

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• 2 years ago

Do you have a preferred message protocol?

VHRanger3• 2 years ago

JSON with a good schema if you're doing it across languages?

jujube3• 2 years ago

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• 2 years ago

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

zeroxfe• 2 years ago

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

aeonik• 2 years ago

I thought Conway's law was fairly prolific.

Though, the closer it is to a true a "law", then the closer GP's comment approaches a tautology.

https://wikipedia.org/wiki/Conway%27s_law

tjpnz• 2 years ago

Did it ever work? I remember having to write some pretty gnarly hacks to work around the broken Python code protoc would barf out. Working outside of Go and perhaps Java/Kotlin I've little faith that they're not going to break things further.

oefrha2• 2 years ago

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.

hot_gril9• 2 years ago

Proto3 already got the required/optional feature added. I don't see why they couldn't have added default values too. (Personally I liked proto3 without optionals, defaults, extensions, etc, but it was a tough sell for people already used to proto2.)

Protobuf Editions are here: don't panic

Related Stories