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.
Protobuf Editions are here: don't panic
11–20 of 58 posts
Re: Protobuf Editions are here: don't panic
#12I 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.
Re: Protobuf Editions are here: don't panic
#13Re: Protobuf Editions are here: don't panic
#14Earlier 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.
Re: Protobuf Editions are here: don't panic
#15I 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...
Re: Protobuf Editions are here: don't panic
#16Re: Protobuf Editions are here: don't panic
#17Re: Protobuf Editions are here: don't panic
#18These 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
#19I 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...
Now just wait for golang packages that have conflicting editions requirements!
Re: Protobuf Editions are here: don't panic
#20Earlier 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.