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.
Protobuf Editions are here: don't panic
21–30 of 58 posts
Re: Protobuf Editions are here: don't panic
#22I'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[...]"
Re: Protobuf Editions are here: don't panic
#23Earlier 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
Re: Protobuf Editions are here: don't panic
#24I 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.
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 > 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
#26Re: Protobuf Editions are here: don't panic
#27I 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.
Re: Protobuf Editions are here: don't panic
#28As 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
#29Earlier 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.
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
#30Oh 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…