Protobuf Editions are here: don't panic(buf.build) |
Protobuf Editions are here: don't panic(buf.build) |
> 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.
> 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.
(BTW, this isn't "shipping their org chart.")
Though, the closer it is to a true a "law", then the closer GP's comment approaches a tautology.
Is the author just annoyed that Buf now has to put in the work to support editions?
ambiguous timeline? sounds right for google.
Thanks Sundar for great org incentive structure!
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.
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.
Now just wait for golang packages that have conflicting editions requirements!
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.
I can attest that the intentions were good, and it’s another tool in our toolbox. A good one, but not the silver bullet sometimes some said.
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"
But even that limited claim is kind of hard to believe. Can you link to one of those multiple sources making that claim?
It's like comparing apples and screwdrivers.
Library/module/API developers often seek to deliver maximimum adaptibility in their interfaces so that consumers of them can satisfy their own more specific/pressing requirements.
With protobuf the schema is essential, it is the foundation. I feel this is a huge advantage especially for communication protocols.
So you have 2 teams do a meeting, we work out a contract we like, dump that into a jsonschema and you can enforce by unit tests that schema is respected on each side (producer/consumer)
We have a bunch of apis like this where I work. It's a huge pain, tbh. You lose the ability to just curl endpoints, or to see what data came over the wire for debugging, not to mention having to use esoteric client libs because every off-the-shelf one just assumes json over http.