Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Protobuf Editions are here: don't panic

buf.build

Post reply on HN
Print view View original

41–50 of 58 posts

Re: Protobuf Editions are here: don't panic

#41

Post by tjpnz »

zeroxfe wrote: post #31
jujube3 wrote: 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…

I don't understand why this is a problem. It's not uncommon to see multi-decade old systems refactored for extensibility and maintainability every once in a while. What worked when it was initially designed won't work forever, and it's hard to make users lives better if the maintainers can't make their own lives better. (BTW, this isn't "shipping their org chart.")

Did it ever work? I remember having to write some pretty gnarly hacks to work around the broken Python code protoc would barf out. Working outside of Go and perhaps Java/Kotlin I've little faith that they're not going to break things further.

Re: Protobuf Editions are here: don't panic

#42

Post by swatcoder »

hot_gril wrote: post #38
swatcoder wrote: post #36

Earlier quoted context omitted.

XML, JSON, and YAML belong to a totally diffent class of use than protobuf, flatbuffers, capnproto, etc It's like comparing apples and screwdrivers.

They're comparable for a lot of use cases. In fact many protobuf-based APIs will also have a JSON mode.

Exactly because the consumers of those API's exhibit a strong preference for one or the other.

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.

Re: Protobuf Editions are here: don't panic

#43

Post by hot_gril »

jon_richards wrote: post #14
hot_gril wrote: post #11

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.

Funny you should mention nullability. That was a big debate in proto2 vs proto3.

Re: Protobuf Editions are here: don't panic

#44

Post by oefrha »

jujube3 wrote: 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…

As a sibling has already pointed out, this blog post has nothing to do with “Google themselves”. In addition, “nothing really for end users” is obviously bullshit and inconsistent with what the post says itself, e.g.

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

Re: Protobuf Editions are here: don't panic

#45

Post by [deleted] »

oefrha wrote: post #44
jujube3 wrote: 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…

As a sibling has already pointed out, this blog post has nothing to do with “Google themselves”. In addition, “nothing really for end users” is obviously bullshit and inconsistent with what the post says itself, e.g. > 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…

[deleted]

Re: Protobuf Editions are here: don't panic

#46

Post by hot_gril »

oefrha wrote: post #44
jujube3 wrote: 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…

As a sibling has already pointed out, this blog post has nothing to do with “Google themselves”. In addition, “nothing really for end users” is obviously bullshit and inconsistent with what the post says itself, e.g. > 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…

Proto3 already got the required/optional feature added. I don't see why they couldn't have added default values too. (Personally I liked proto3 without optionals, defaults, extensions, etc, but it was a tough sell for people already used to proto2.)

Re: Protobuf Editions are here: don't panic

#47

Post by oefrha »

hot_gril wrote: post #46
oefrha wrote: post #44

Earlier quoted context omitted.

As a sibling has already pointed out, this blog post has nothing to do with “Google themselves”. In addition, “nothing really for end users” is obviously bullshit and inconsistent with what the post says itself, e.g. > 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…

Proto3 already got the required/optional feature added. I don't see why they couldn't have added default values too. (Personally I liked proto3 without optionals, defaults, extensions, etc, but it was a tough sell for people already used to proto2.)

They can, and feature flags is one flexible (if somewhat verbose) way to do it.

Re: Protobuf Editions are here: don't panic

#48

Post by hot_gril »

hot_gril wrote: post #10

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

Thinking about this more, this looks overly dismissive. Seems Google wants to be very explicit about future syntax and allow users to mix in different features. I don't think it's worthwhile, but it's doing something.

Is the author just annoyed that Buf now has to put in the work to support editions?

Re: Protobuf Editions are here: don't panic

#49

Post by dilyevsky »

perezd wrote: post #17
beeboobaa3 wrote: post #16

Earlier quoted context omitted.

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.

Meh, that's too easy now - if you really want to prove it post something politically incorrect.

Re: Protobuf Editions are here: don't panic

#50

Post by dilyevsky »

akshayshah wrote: post #20
jsnell wrote: 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.

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.

proto1 was designed by Sanjay and Jeff, proto2 by Kenton Varda (who later designed Cap'n'Proto), proto3 I can't remember who but I never heard Rob Pike being credited with this. He did write the very first Go proto binding package though and a separate serialization package called gob with a totally separate rpc library.
Post reply on HN