Live data from Hacker News

Protobuf Editions are here: don't panic

buf.build

21–30 of 58 posts

Re: Protobuf Editions are here: don't panic

#21
post #12
post #9

Earlier quoted context omitted.

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.

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.

"i came up with the term 'protobuf', and go was not what i had in mind" -rob pike

Re: Protobuf Editions are here: don't panic

#22

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

Design by promo.

Re: Protobuf Editions are here: don't panic

#23
post #12

Earlier quoted context omitted.

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.

"i came up with the term 'protobuf', and go was not what i had in mind" -rob pike

https://go.dev/blog/gob

Re: Protobuf Editions are here: don't panic

#24
post #9

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

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.

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.

Re: Protobuf Editions are here: don't panic

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

Re: Protobuf Editions are here: don't panic

#27
post #8

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

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.

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

Re: Protobuf Editions are here: don't panic

#28
post #18

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.

Do you have a preferred message protocol?

Re: Protobuf Editions are here: don't panic

#29

Earlier quoted context omitted.

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

The number of APIs with a single JSON example as the only documentation is... unfortunate. Especially if you want to know if a field is nullable.

Taking this a bit further, it's surprising how many companies sell API as a service but provide minimal support for that API, publishing like 1 client/sdk (and often not in the language you need, lol).

Just mindblowing that companies don't adopt a schema-first approach to appeal to a broader customer base. I've lost count of the number of hnd rolled clients I've had to write over the years.

It gets even better if the API itself is backed by some RPC framework. With that, users can simply generate a client and get going.

It feels like we can do better as an industry, this cracked me up because it's so true.

"a single JSON example as the only documentation is... unfortunate"

Re: Protobuf Editions are here: don't panic

#30
post #25

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 impa…

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