A new Go API for Protocol Buffers • Hacker News Board

Re: A new Go API for Protocol Buffers

#11

Post by giancarlostoro » Mon, Mar 02, 2020, 9:20 PM 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…

Would be nice if they would just make packages.golang.org sorta how Python has PyPI, Rust has Crates.IO and so on... They can just redirect to relevant repos...

Re: A new Go API for Protocol Buffers

#12

Post by farslan » Mon, Mar 02, 2020, 9:20 PM UTC

neild wrote: post #9

farslan wrote: post #7

Earlier quoted context omitted.

Because they would had to add a `/v2` suffix to the import path and seems like they didn't wanted to add that. The question is, why is this not released as v1.0.0 then? Still trying to understand the reasoning for this.

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…

Thanks for the all the work. And I hope my rant doesn't come something as a bad. But I truly believe the versioning along with the import path is confusing. I hope the team goes over the versioning again and come up with something that makes more sense.

Re: A new Go API for Protocol Buffers

#13

Post by cube2222 » Mon, Mar 02, 2020, 9:23 PM UTC

Congrats on the big release!

One thing which saddens me a lot though, is returning types you have to type assert because they had to avoid an import cycle. I don’t know if it could be avoided (probably not) but it’s still unergonomic.

> (Why the type assertion? Since the generated descriptorpb package depends on protoreflect, the protoreflect package can't return the concrete options type without causing an import cycle.)

Re: A new Go API for Protocol Buffers

#14

Post by llimllib » Mon, Mar 02, 2020, 9:26 PM UTC

neild wrote: post #9

farslan wrote: post #7

Earlier quoted context omitted.

Because they would had to add a `/v2` suffix to the import path and seems like they didn't wanted to add that. The question is, why is this not released as v1.0.0 then? Still trying to understand the reasoning for this.

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…

When I read the article, my brain passed right over the different domain names; the two are even the exact same number of characters, set in a monospace font, and my brain passes right over the domain of golang imports to the end of the path. That's where the interesting bit is (usually!)

I find this a super confusing and unintuitive choice, but I suppose it's too late for changing it now.

Sincerely, an othwerwise mostly happy protobuf user

Re: A new Go API for Protocol Buffers

#15

Post by rverghese » Mon, Mar 02, 2020, 9:38 PM UTC

neild wrote: post #9

farslan wrote: post #7

Earlier quoted context omitted.

Because they would had to add a `/v2` suffix to the import path and seems like they didn't wanted to add that. The question is, why is this not released as v1.0.0 then? Still trying to understand the reasoning for this.

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?

Re: A new Go API for Protocol Buffers

#16

Post by bouk » Mon, Mar 02, 2020, 9:44 PM UTC

neild wrote: post #9

farslan wrote: post #7

Earlier quoted context omitted.

Because they would had to add a `/v2` suffix to the import path and seems like they didn't wanted to add that. The question is, why is this not released as v1.0.0 then? Still trying to understand the reasoning for this.

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…

You could give google.golang.org/protobuf@v1 an //importpath to the github package, so go would warn people about it.

Re: A new Go API for Protocol Buffers

#17

Post by tsimionescu » Mon, Mar 02, 2020, 9:46 PM UTC

neild wrote: post #9

farslan wrote: post #7

Earlier quoted context omitted.

Because they would had to add a `/v2` suffix to the import path and seems like they didn't wanted to add that. The question is, why is this not released as v1.0.0 then? Still trying to understand the reasoning for this.

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…

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

This seems like a good example why tying the name of the package in the code with the place where it can be downloaded was a very bad idea. Simply changing hosting providers is now a backwards compatibility break for your clients.

If Go imports didn't work this way, you could have simply offered the old v1 from both github.com and google.golang.org, and used a clear v2 for the v2. Sure , you would have similar problems if you wanted to change the logical package structure for some reason (say, when an open-source package moves to a different organization), but that is a much rarer case than switching code repos.

However, given that that ship has probably long sailed, you probably picked the right choice.

I would also note that v2 in the import path feels a bit strange, since it makes users of the newest code need to know about the history of the package, but there are also clear advantages which probably out-weigh this (I believe this is absolutely not the case for the decision to include the hosting provider in the import path).

Re: A new Go API for Protocol Buffers

#18

Post by rolleiflex » Mon, Mar 02, 2020, 9:48 PM UTC

neild wrote: post #9

farslan wrote: post #7

Earlier quoted context omitted.

Because they would had to add a `/v2` suffix to the import path and seems like they didn't wanted to add that. The question is, why is this not released as v1.0.0 then? Still trying to understand the reasoning for this.

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…

I think you’re overestimating how much people pay attention to the body part of the import paths. Since there have been a quite few projects that implemented a sort of redirect (i.e. ‘vanity’ imports [0]) most people’s eyes just glaze over the small change in the URL.

I would strongly suggest using /v2 at the end. /v1 not existing on *.golang.org is not a problem in practice, but if it ends up one you could just set that up as a vanity import pointing to github.com for the old version.

[0] https://sagikazarmark.hu/blog/vanity-import-paths-in-go/

Re: A new Go API for Protocol Buffers

#19

Post by endorphone » Mon, Mar 02, 2020, 9:58 PM 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.

"we just really wanted to stop using an import path tied to a specific hosting provider"

e.g. github is now owned by Microsoft and it's a little awkward.

If Google won out on their attempt to buy Github, they wouldn't wouldn't be talking about a "specific hosting provider".

Though it's a little weird that people take this at face value, when the majority of the userbase was questioning this since the first release.

Re: A new Go API for Protocol Buffers

#20

Post by neild » Mon, Mar 02, 2020, 10:01 PM UTC

tsimionescu wrote: post #17

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…

> 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. This seems like a good example why tying the name of the package in the code with the place where it can be downloaded was a very bad idea. Simply changing hosting providers is now a backwards compatibility break for your clients. If Go impor…

Indeed, tying the name of a package to a hosting provider is a bad idea! That's why we changed to an import path which isn't tied to one. google.golang.org/protobuf is not tied to any particular provider, and we can redirect it wherever we want.

See "go help importpath" for details on how this works.