Live data from Hacker News

Protobuf Editions are here: don't panic

buf.build

11–20 of 58 posts

Re: Protobuf Editions are here: don't panic

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

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

Re: Protobuf Editions are here: don't panic

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

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.

Re: Protobuf Editions are here: don't panic

#14
post #8

Earlier quoted context omitted.

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.

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.

Re: Protobuf Editions are here: don't panic

#17
post #4

Earlier quoted context omitted.

What’s the meaning behind this comment?

looks like an LLM spambot

lol, well. Sorry man, I'm a real boy. Check my account age. I can solve some math problems or look at what photos are bridges if you want.

Re: Protobuf Editions are here: don't panic

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

Re: Protobuf Editions are here: don't panic

#19

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

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!

Re: Protobuf Editions are here: don't panic

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

Per multiple sources, including the team currently maintaining the Protobuf toolchain within Google, proto3 was largely designed by Rob Pike. Of course the Protobuf wire format is quite a bit older, but some aspects of proto3 and Go's shared semantics (like implicit zero values) do seem to have come from the same mind.
Post reply on HN