3 ms·

> 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

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

EdwardDiego 7y ago
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.
heydabop 7y ago
> the now deprecated— GOPATH environment variable I've been writing Go since 2015ish and this is news to me...
breakingcups 7y ago
I loved Go's simplicity when it came out. However, it has become clear to me that it was a little too simple to handle all the new requirements and additions that came after v1. That's how you get weird comments-as-code (// +build linux,386 darwin,!cgo), strings-as-attributes (tags), tacked-on modules versioning / vendoring, non-typed generics( interface{} everywhere), somewhat-typed generics (go generate), etc. Go was not quite ready to handle all these directions people wanted the language to stretch to and as a result it's now already full of annoying warts. I'll still pick Go if I need a simple service with amazing performance. Funnily enough though, I have no need for any of the (non-performance) additions that came after 1.6.

EdwardDiego 7y ago

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.

heydabop 7y ago

> the now deprecated— GOPATH environment variable I've been writing Go since 2015ish and this is news to me...

breakingcups 7y ago

I loved Go's simplicity when it came out. However, it has become clear to me that it was a little too simple to handle all the new requirements and additions that came after v1. That's how you get weird comments-as-code (// +build linux,386 darwin,!cgo), strings-as-attributes (tags), tacked-on modules versioning / vendoring, non-typed generics( interface{} everywhere), somewhat-typed generics (go generate), etc. Go was not quite ready to handle all these directions people wanted the language to stretch to and as a result it's now already full of annoying warts. I'll still pick Go if I need a simple service with amazing performance. Funnily enough though, I have no need for any of the (non-performance) additions that came after 1.6.