A new Go API for Protocol Buffers • Hacker News Board

Re: A new Go API for Protocol Buffers

#61

Post by twblalock » Tue, Mar 03, 2020, 3:51 AM UTC

neild wrote: post #3

zdw wrote: post #2

Interesting that even Google decided to do complex versioning gymnastics and introduce a new namespace in order to avoid how `go mod` adds the version as a path component.

Nah, we just really wanted to stop using an import path tied to a specific hosting provider. Once we decided to change to an entirely different path, we waffled a lot over whether to tag it v1 or v2. There were arguments for and against either, so we eventually picked one and went with it.

The whole idea of tying image names to hosting provider urls or other kinds of locators was probably a bad idea.

What if those things move to different domains, or different directory structures? Wouldn't that break every Go program that depends on them?

I've been using Java, Python, and Ruby for a while. They all have various pain points for managing dependencies but they do get one thing right: packages have names and versions, names are opaque strings that are not coupled to a particular hosting provider, and they don't care what directory on my laptop I use to store my dependencies and my code.

The Go dependency model seems like a real step backwards in usability and maintenance. It's like they are forcing one software org's standards on the rest of us. We don't all work at Google! Just let us depend on things that have names and version numbers!

Re: A new Go API for Protocol Buffers

#62

Post by bhawks » Tue, Mar 03, 2020, 3:53 AM UTC

atombender wrote: post #32

Hopefully this is good news. The old Protobuf package had ossified, with lots of ergonomic issues that the maintainers seemed uninterested in addressing. One perennial annoyance is how awkwardly some Protobuf stuff ends up being represented in Go. For example, "oneof" types: message Event { oneof payload { Create create = 1; Delete delete = 2; } } message Create { string id = 1; } message Delete { string version = 1;…

The original golang codegen omitted oneof support completely on the grounds that the concept didn't apply to golang.

Eventually they realized that oneof isnt an optional feature of proto - but the solution always felt rushed and bolted on because it was.

I hope the second try at proto api addresses these warts. I'm generally a golang fan - but not in this area.

Citations:

https://github.com/golang/protobuf/issues/29

Re: A new Go API for Protocol Buffers

#63

Post by 7532yahoogmail » Tue, Mar 03, 2020, 3:56 AM UTC

AaronFriel wrote: post #35

Not to be too Rust evangelist here, but why the emphasis on reflection instead of further support for generics? On the Rust side, macros can[1] transform .proto files into data structure definitions at compile time, and instances of the structs passed around have the benefit of strong typing, code completion in editors, lints and tests can easily validate properties of protobuf objects and so on. And all without addi…

But the protoc compiler already makes data structure definitions in the target, client language. So what's the point of a parallel macro system? Either it's a subset of capability of what protoc does or equal. Former questionable; latter redundant.

Re: A new Go API for Protocol Buffers

#64

Post by 7532yahoogmail » Tue, Mar 03, 2020, 3:58 AM UTC

Umm ... When will pb allow me to decode a field in buffer without having to decode the entire object in the buffer? I'm talking a field in a pb message NOT a byte stream I hand encoded without reference to a message eg more like flat buffers.

Re: A new Go API for Protocol Buffers

#65

Post by justlexi93 » Tue, Mar 03, 2020, 4:05 AM UTC

It is odd that the Go team is all in on semantic import paths, but basically everyone else is like “I will blow up the moon if it means I don’t have to use v2 in my import path.

Re: A new Go API for Protocol Buffers

#66

Post by mfcl » Tue, Mar 03, 2020, 4:09 AM UTC

justlexi93 wrote: post #65

It is odd that the Go team is all in on semantic import paths, but basically everyone else is like “I will blow up the moon if it means I don’t have to use v2 in my import path.

v2 is used so that the import path is different. The idea is that by breaking the API, you are basically making a new module instead of improving one (metaphorically of course), and it doesn't make sense for the same module to have the same import path.

If you want to change the import path and also release a new version, then simply changing the import path is enough. No need to put v2.

See it as them releasing a totally new package that just happens to have the same name, if that helps.

Re: A new Go API for Protocol Buffers

#67

Post by mastrsushi » Tue, Mar 03, 2020, 4:58 AM UTC

Hackernews, where the highlight of mentioning common libraries is the fact that they're done so in Go and Rust.

Re: A new Go API for Protocol Buffers

#68

Post by heydabop » Tue, Mar 03, 2020, 5:05 AM UTC

dgellow wrote: post #4

> The github.com/golang/protobuf module is APIv1. > The google.golang.org/protobuf module is APIv2. We have taken advantage of the need to change the import path to switch to one that is not tied to a specific hosting provider. That's such a weird choice, and will be quite confusing. Now every time you see protobuf being imported, you have to be sure to pay extra attention to the domain used, and correctly remember w…

I've seen many people append a version to the package name. So they could have done `protobuf.v2` (granted the original would be missing a version but still, at least this is more explicit)

Re: A new Go API for Protocol Buffers

#69

Post by heydabop » Tue, Mar 03, 2020, 5:06 AM UTC

guessmyname wrote: post #41

> The github.com/golang/protobuf module is APIv1. > The google.golang.org/protobuf module is APIv2. > We have taken advantage of the need to change the import path to switch to one that is not tied to a specific hosting provider. > (Why start at version v1.20.0? To provide clarity. We do not anticipate APIv1 to ever reach v1.20.0, so the version number alone should be enough to unambiguously differentiate between API…

> the now deprecated— GOPATH environment variable

I've been writing Go since 2015ish and this is news to me...

Re: A new Go API for Protocol Buffers

#70

Post by DougBTX » Tue, Mar 03, 2020, 7:20 AM UTC

dgellow wrote: post #4

> The github.com/golang/protobuf module is APIv1. > The google.golang.org/protobuf module is APIv2. We have taken advantage of the need to change the import path to switch to one that is not tied to a specific hosting provider. That's such a weird choice, and will be quite confusing. Now every time you see protobuf being imported, you have to be sure to pay extra attention to the domain used, and correctly remember w…

They did get one benefit from this choice:

> the version number alone should be enough to unambiguously differentiate between APIv1 and APIv2.

...which is how version numbers normally work. They've made a big breaking change in a 1.X release, so it isn't semver, but that isn't the end of the world. It works around having to put the major version number in the import path too, so really it works like most other non-Go, non-semver, projects.