Go 1.16 is released

[Alex Rakoczy]

Hello gophers,

We just released Go 1.16

To find out what has changed in Go 1.16, read the release notes:
https://golang.org/doc/go1.16

You can download binary and source distributions from our download page:
https://golang.org/dl/

If you have Go installed already, an easy way to try go1.16
is by using the go command:
$ go get golang.org/dl/go1.16
$ go1.16 download

To compile from source using a Git clone, update to the release with
"git checkout go1.16" and build as usual.

Thanks to everyone who contributed to the release!

Cheers,
Alex and Dmitri for the Go Team

[Peter Kleiweg]

`go get` is broken. It doesn't download packages.

Op dinsdag 16 februari 2021 om 20:56:37 UTC+1 schreef Alex Rakoczy:

[Ian Lance Taylor]

On Tue, Feb 16, 2021 at 12:34 PM Peter Kleiweg <pkle...@xs4all.nl> wrote:
>
> `go get` is broken. It doesn't download packages.

Tell us what you did, what you expected to happen, and what happened
instead. Thanks.

Note that module support is now on by default
(https://golang.org/doc/go1.16#go-command), which can affect the
behavior of "go get".

Ian

[Brad Fitzpatrick]

Elaborate?

On Tue, Feb 16, 2021 at 12:34 PM Peter Kleiweg <pkle...@xs4all.nl> wrote:

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/040e8124-7675-4767-9348-90ab88908ac8n%40googlegroups.com.

[Fernando Meyer]

$ go get -u github.com/boyter/scc/
go: downloading github.com/boyter/scc v1.12.1
go: downloading github.com/boyter/scc v2.12.0+incompatible
go: downloading github.com/spf13/cobra v1.1.3
go: downloading golang.org/x/text v0.3.5
go: downloading gopkg.in/yaml.v2 v2.4.0
go: downloading github.com/dbaggerman/cuba v0.3.2
go: downloading github.com/minio/blake2b-simd v0.0.0-20160723061019-3f5f724cb5b1
go: downloading github.com/monochromegane/go-gitignore v0.0.0-20200626010858-205db1a8cc00
~ took 12s
$ go get -u github.com/rakyll/gotest
go: downloading github.com/rakyll/gotest v0.0.5
go: downloading github.com/mattn/go-isatty v0.0.11
go: downloading golang.org/x/sys v0.0.0-20191026070338-33540a1f6037
go: downloading golang.org/x/sys v0.0.0-20210216163648-f7da38b97c65
~ took 3s
$ go version
go version go1.16 linux/amd64

I just tested on both linux and M1 and it's working for me. What OS have you tried?

Are you facing any networking issues?
Can you ping github.com?


Best,

--
Fernando Meyer

> --
> You received this message because you are subscribed to the Google Groups "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/040e8124-7675-4767-9348-90ab88908ac8n%40googlegroups.com <https://groups.google.com/d/msgid/golang-nuts/040e8124-7675-4767-9348-90ab88908ac8n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Peter Kleiweg]

Op dinsdag 16 februari 2021 om 21:40:52 UTC+1 schreef Ian Lance Taylor:

On Tue, Feb 16, 2021 at 12:34 PM Peter Kleiweg  wrote:
>
> `go get` is broken. It doesn't download packages.

Tell us what you did, what you expected to happen, and what happened
instead. Thanks.

Note that module support is now on by default
(https://golang.org/doc/go1.16#go-command), which can affect the
behavior of "go get".

Ian

 Ah, modules are the culprit. When I set `GO111MODULE=auto` everything works as it should.

Without `GO111MODULE=auto` :

 - `go get` doesn't download to $GOPATH/src

 - `go build` doesn't work with packages in `$GOPATH/src`

This means you can't use packages that need modification to an unusual environment.

Also, you can't use local packages without a dot in the name.

So why would you ever want to *not* set `GO111MODULE=auto` ?

[Carla Pfaff]

On Tuesday, 16 February 2021 at 22:57:07 UTC+1 pkle...@xs4all.nl wrote:

Also, you can't use local packages without a dot in the name.

I do this all the time.

[Wojciech S. Czarnecki]

Dnia 2021-02-16, o godz. 13:57:06
Peter Kleiweg <pkle...@xs4all.nl> napisał(a):

> So why would you ever want to *not* set `GO111MODULE=auto` ?
>

Because GOPATH mode is gonna to be slayed soon.
It is better to use it less and less to avoid future disruption.

Hope this helps,

--
Wojciech S. Czarnecki
<< ^oo^ >> OHIR-RIPE

[Richard Grosman]

Please refer to this blog post https://blog.golang.org/using-go-modules to get to know why go modules are better than using GOPATH (primarly for not messing with the import paths).

You are free to setup a local repository (localhost) by issuing the following commands in your project directory outside the GOPATH:

`go mod init localhost.repository` (not matching an existing domain.tld; creates a go.mod file)

`go mod tidy` (maintains and cleans up dependencies)

Now `go get -u` downloads and upgrades packages appropriately.

[simon place]

nothing compiles any more!

i seem to be being forced to add, to some projects 9 years old (unnecessary) module support, or, add notes to all their docs that they need to be compiled in versions older than 1.16, or have to have an obscure parameter set.

there really wasn't a non-breaking way to do this?

seems to me this has effectively become part of the language and should be implemented in accordance with the go1 backward compat. guarantee. what difference does it make to a user when things stop compiling like this.

[Kurtis Rader]

On Tue, Feb 23, 2021 at 5:03 PM 'simon place' via golang-nuts <golan...@googlegroups.com> wrote:

nothing compiles any more!

i seem to be being forced to add, to some projects 9 years old (unnecessary) module support, or, add notes to all their docs that they need to be compiled in versions older than 1.16, or have to have an obscure parameter set.

there really wasn't a non-breaking way to do this?

seems to me this has effectively become part of the language and should be implemented in accordance with the go1 backward compat. guarantee. what difference does it make to a user when things stop compiling like this.

On Tuesday, 16 February 2021 at 19:56:37 UTC Alex Rakoczy wrote:

Insufficient information. What command did you run? What was the output? Note that module mode is now the default with Go 1.16. You can get the Go 1.15 behavior by exporting GO111MODULE=auto. However,  that will just punt the problem down the road. At some point in the future GOPATH mode will no longer be supported. You're probably better off biting the bullet now and switching to Go modules.

P.S., Note that I deliberately changed the subject line to start a new thread.

--

Kurtis Rader

Caretaker of the exceptional canines Junior and Hank

[simon place]

On Wednesday, 24 February 2021 at 02:26:39 UTC Kurtis Rader wrote:

On Tue, Feb 23, 2021 at 5:03 PM 'simon place' via golang-nuts <golan...@googlegroups.com> wrote:

nothing compiles any more!

i seem to be being forced to add, to some projects 9 years old (unnecessary) module support, or, add notes to all their docs that they need to be compiled in versions older than 1.16, or have to have an obscure parameter set.

there really wasn't a non-breaking way to do this?

seems to me this has effectively become part of the language and should be implemented in accordance with the go1 backward compat. guarantee. what difference does it make to a user when things stop compiling like this.

On Tuesday, 16 February 2021 at 19:56:37 UTC Alex Rakoczy wrote:

Insufficient information. What command did you run? What was the output? Note that module mode is now the default with Go 1.16. You can get the Go 1.15 behavior by exporting GO111MODULE=auto. However,  that will just punt the problem down the road. At some point in the future GOPATH mode will no longer be supported. You're probably better off biting the bullet now and switching to Go modules.

thanks, but i did read the tread.

> Insufficient information. What command did you run? What was the output

you seem to not get it, i provide the go SOURCE in a repo, who ever wants to use it package will try to compile and now with 1.16 all will fail, without me retrospectively changing them all.

i guess i won't do anything, shame, just way too much work, i'll just have to rely on people knowing they need <1.16, (or the parameter) at least this will be so common a problem it will probably be well enough known.

things like this, and i do this, if a new package doesn't work first time, i walk away.

but then, thinking about it, what happens when you have a project with a mixture of moduled and non-moduled imports, very hard to get working? so if i don't put in the, completely unnecessary, work i may as well just scrap the lot.

 

[simon place]

you could just make non-modules repos 'look like' a module with one version.

[Kurtis Rader]

On Tue, Feb 23, 2021 at 7:24 PM 'simon place' via golang-nuts <golan...@googlegroups.com> wrote:

Insufficient information. What command did you run? What was the output? Note that module mode is now the default with Go 1.16. You can get the Go 1.15 behavior by exporting GO111MODULE=auto. However,  that will just punt the problem down the road. At some point in the future GOPATH mode will no longer be supported. You're probably better off biting the bullet now and switching to Go modules.

thanks, but i did read the tread.

What did you read? The thread that you originally replied to simply announced a new Go release. Something that happens roughly every six months and always has the potential of disrupting existing users of the Go toolchain.

 

> Insufficient information. What command did you run? What was the output

you seem to not get it, i provide the go SOURCE in a repo, who ever wants to use it package will try to compile and now with 1.16 all will fail, without me retrospectively changing them all.

If you are publishing your Go project(s) you should be using modules. Regardless, you still haven't provided any information that would allow the Go community to help you. Provide a link to your repo and/or describe the structure of your repo and how you expect it to be used.

i guess i won't do anything, shame, just way too much work, i'll just have to rely on people knowing they need <1.16, (or the parameter) at least this will be so common a problem it will probably be well enough known.

things like this, and i do this, if a new package doesn't work first time, i walk away.

but then, thinking about it, what happens when you have a project with a mixture of moduled and non-moduled imports, very hard to get working? so if i don't put in the, completely unnecessary, work i may as well just scrap the lot.

I get the sense you're not really asking for help; you're just interested in expressing unhappiness that the world has changed.

[Jon Reiter]

i had a similar experience where i ended up pull-requesting the addition of mod&sum into a dependency.  fair enough for actively maintained packages or packages you've contributed to before but could be problematic otherwise.   (insert any linux/bsd talk about contributing changes upstream here)

it is not really reasonable to expect everyone to indefinitely maintain everything they put out there.  this is a breaking change for old code in practice...even if it's more the toolchain than the source and consistent with the compatibility promise when carefully read.  to be clear: i'm not criticising the change and like that i need to take action(s) now as opposed to an unknown time later.

so a suggestion: a tool to scan for not-updated projects that does the mod&tidy, tests it, and sends a pull request.  logistically that's a lot for an individual but should be workable for the go team (i am guessing).  this would also have the advantage of finding truly orphaned projects -- if a maintainer doesn't reply in a week/month/whatever to an obviously-automatic-and-official request to fix something the package really should be forked.  can't cover everything but whatever is on pkg.go.dev is a kind of all you can expect.

and if anybody from the hosting/ci providers is here: providing free credits for this would be a nice way to show support for the ecosystem.

or maybe this is just going to cause noise for a week and then every actively used package will be sorted or forked-and-then-sorted.

--

You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CABx2%3DD8gGZOwnY%3D_gcs%2BayGeZgDjpCM%3DuHTe6HSuw9n945Qvow%40mail.gmail.com.

[Amnon]

Go modules were introduced back in 2018, so we have had a good few years to 
migrate. In most cases migrating simply means running go mod init,  and 
commiting the go.mod and go.sum files.
Migrating does cause a small amount of pain. But it will improve your life
as a developer.

The existence of both GOPATH and Module modes has been a source of
confusion in the Go world. So obliterating GOPATH, and its bizarre stipulations about how 
you need to organise your home directory is welcome, and long overdue.

[simon place]

On Wednesday, 24 February 2021 at 08:10:01 UTC jonr...@gmail.com wrote:

i had a similar experience where i ended up pull-requesting the addition of mod&sum into a dependency.  fair enough for actively maintained packages or packages you've contributed to before but could be problematic otherwise.   (insert any linux/bsd talk about contributing changes upstream here)

it is not really reasonable to expect everyone to indefinitely maintain everything they put out there.  this is a breaking change for old code in practice...even if it's more the toolchain than the source and consistent with the compatibility promise when carefully read.  to be clear: i'm not criticising the change and like that i need to take action(s) now as opposed to an unknown time later.

so a suggestion: a tool to scan for not-updated projects that does the mod&tidy, tests it, and sends a pull request.  logistically that's a lot for an individual but should be workable for the go team (i am guessing).  this would also have the advantage of finding truly orphaned projects -- if a maintainer doesn't reply in a week/month/whatever to an obviously-automatic-and-official request to fix something the package really should be forked.  can't cover everything but whatever is on pkg.go.dev is a kind of all you can expect.

and if anybody from the hosting/ci providers is here: providing free credits for this would be a nice way to show support for the ecosystem.

or maybe this is just going to cause noise for a week and then every actively used package will be sorted or forked-and-then-sorted.

thanks. expressed virtually all i was about too.

BTW something i just noticed.....

i lean on the std.lib. for patterns/references/best practice, how come its not modularised?

[Amnon]

Because stdlib was written before modules were a thing.

Regarding the "lets keep GOPATH going" argument, there was an issue about this on github where the 
arguments around the issue were fully explored.

https://github.com/golang/go/issues/37755#issuecomment-771879911