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

A new Go API for Protocol Buffers

blog.golang.org

Post reply on HN
Print view View original

41–50 of 100 posts

Re: A new Go API for Protocol Buffers

#41

Post by guessmyname »

> 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 APIv1 and APIv2.)

Stuff like this is what makes Go confusing to newcomers.

For some time I couldn’t understand why people were complaining so much about —the now deprecated— GOPATH environment variable, and later the confusion of how to use all the different and incompatible dependency managers. Then, suddenly last year, it hits me… Go is confusing to people who haven’t followed the language from the beginning.

I started programming in Go in 2013 so for me it was very easy to adapt to every change in the language and the community.

I can only imagine all the ambiguous stuff people have to understand when learning the language in 2019-2020.

Re: A new Go API for Protocol Buffers

#42

Post by BarkMore »

Insanity wrote: post #40
icholy wrote: post #10

Earlier quoted context omitted.

> If only go modules established a clear way to differentiate API versions using the import path! It did, they just chose not to follow it :/ I wonder what rsc thinks about this decisions

Rsc?

Russ Cox https://news.ycombinator.com/user?id=rsc

Re: A new Go API for Protocol Buffers

#43

Post by paulddraper »

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.

So both old and new are available through the new domain?

Re: A new Go API for Protocol Buffers

#44

Post by dana321 »

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;…

Its horrible, i know. Try mixing that with grpc too and it gets even worse.

Re: A new Go API for Protocol Buffers

#46

Post by EdwardDiego »

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…

I think the bit that got me around GOPATH was last time I'd written Go, that was the only way. Then I fired up Go again, v1.12 and decided to take advantage of a Go module for a new project, which I naturally put beside my existing Go code. And then I got to learn about the settings for GO111MODULE.

Having the build tools a core part of your language itself is both a strength and a weakness for Go, I think.

Re: A new Go API for Protocol Buffers

#47

Post by manigandham »

sigzero wrote: post #22

I thought the general consensus on protocol buffers was "Meh"?

Why would it be? At this point, it's a simple, effective and fast RPC framework with a lot of cross-language support. If you need something like it, there's not many other choices available with this big of an ecosystem.

There's even GRPC-Web being worked on to bring it to the browser. That being said, it can be overused just like anything else.

Re: A new Go API for Protocol Buffers

#48

Post by _y5hn »

neild wrote: post #21
rverghese wrote: post #15

Earlier quoted context omitted.

What are you going to do for APIv3? Version it as google.golang.org@v2? google.golang.org@v3 (but @v2 doesn't exist)? Release an @v2 which is identical to @v1?

We used up our breaking change budget for the next decade with this release, so we'll think about it in 2030.

Admit it, once Windows 22 is out the door, protobuf 1.22 is shippin' as well! Yieehaaw!

Rust .22 with breaking changes, will be breaking 4 years after that as well!

Re: A new Go API for Protocol Buffers

#49

Post by nly »

sigzero wrote: post #22

I thought the general consensus on protocol buffers was "Meh"?

It is a bit meh. The IDL and generated code is very ugly, and its neither the fastest nor the most compact (in serialized bytes) format. That said, it's also very widely adopted, and very mature.

Re: A new Go API for Protocol Buffers

#50

Post by uluyol »

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…

Compile time generic programming is not a replacement for runtime reflection. A great example of this is if you want to use dynamically generated protocol buffers.

A great usecase for this is if you want to store each row in a database as a proto message. Instantiate a descriptor based on the table schema and go.

Post reply on HN