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

21–30 of 100 posts

Re: A new Go API for Protocol Buffers

#21

Post by neild »

rverghese wrote: post #15
neild wrote: post #9

Earlier quoted context omitted.

Reasoning went something like this: We could tag the new API v2: + Makes the "v1" and "v2" distinction very clear in the import path. - Confusing: google.golang.org/protobuf@v1 doesn't exist, but v2 does. - In ten years, hopefully nobody cares about the old github.com/golang/protobuf and the confusion is gone. We could tag the new API v1: - Less visually distinct in the import path. + Seems to make sense for the firs…

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.

Re: A new Go API for Protocol Buffers

#23

Post by kardianos »

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…

The goal of issuing a major version is to create a separate package namespace so it can be imported concurrently to other major versions. By treating major versions as different packages, it creates efficiencies in VCS history and common namespace.

However, the goal is to create a new package name that can be concurrently imported with previous versions. Everything else is just method. Don't confuse the goal with the method.

Re: A new Go API for Protocol Buffers

#24

Post by [deleted] »

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…

[deleted]

Re: A new Go API for Protocol Buffers

#26

Post by capableweb »

sigzero wrote: post #22

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

I'm wondering if the whole idea behind "general consensus" really work on technical problems. There are so many factors involved with the choices engineers make that you can't say that general consensus says it's "meh" as it really depends on your use case. No tool will ever fit all general problems, so will always be "meh" for someone.

Re: A new Go API for Protocol Buffers

#28

Post by alkonaut »

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…

Then you see the version imported being v1.X where X>20 and of course that makes it obvious that it’s v2?

Are version numbers 2.0 and higher explicitly banned?

Edit: found an explanation further down (spoiler: not a very good one but a very go one).

Re: A new Go API for Protocol Buffers

#30

Post by xmprt »

myko wrote: post #29
sigzero wrote: post #22

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

I think for large organizations they probably make sense. They're potentially a lot less data per request than JSON. For the average app? Overkill, sure.

I also recently learned about grpcurl that makes using protobufs a lot easier. Still not as easy as json but I think protobufs are the future.
Post reply on HN