
What's Coming in Go 1.14 [slides] - ngaut
https://docs.google.com/presentation/d/1HfIwlVTmVWQk94OLKfTGvXpQxyp0U4ywG1u5j2tjiuE/mobilepresent?slide=id.g550f852d27_228_0
======
geoah
Go 1.13 has been by far the worse release in my memory. The go ecosystem and
community was not ready nor prepared for modules.

Enabling by default the sum database broke a number of codebases that had
altered the history of their codebases (either themselves or their
dependencies). This should have been an opt in feature for this version.

Changing the way the pseudoversion behaves by expecting a correct date and
specific sha length broke a larger number of codebases. This should have been
a warning on this version and not cause the modules to fail.

There was one more change that I have wiped from my memory that broke athens.
It has to do with how go now looks for a go.mod file in parent urls that
caused athens to return a 500.

Overall spent about a week of swearing and trying to fix tools and deps. At
the end gave up and moved back to 1.12.

~~~
kardianos
This is in stark contrast to my experience, which was great.

Were you able to file any issues or explain to people what happened?

~~~
geoah
Hey kardianos, first of all thank you for all your hard work with getting the
golang community a worthy dep manager.

\---

As for reporting the issues, it's something I assumed is common knowledge from
the fact that any dep I had an issue with on the first day of 1.13 already had
a bug filled.

Searching for `"invalid pseudo-version"` in github results in around 80 issues
in different repositories that all have to do with go 1.13 and modules. [1]

Similarly a search for `golang "checksum mismatch"` will result in over 130
issues in regards to the sum db complaining about broken builds. [2]

There will be more that are not been correctly reported in github issues, and
there will be false reports as well. But the repos that show up will have
caused cascade issues.

We couldn't use golangci-lint for a couple of days before it was fixed. There
is a limit to the amount of mod replaces I can live with before deciding it's
not worth it.

Don't get me wrong. I do like mod, but I just think that for a language that
prides itself on "backwards compatibility" it's doing a pretty poor job at
keeping the same promise when mod is involved.

\---

[1] [https://github.com/search?q=%22invalid+pseudo-
version%22+is%...](https://github.com/search?q=%22invalid+pseudo-
version%22+is%3Aissue&type=Issues)

[2]
[https://github.com/search?q=golang+%22checksum+mismatch%22+i...](https://github.com/search?q=golang+%22checksum+mismatch%22+is%3Aissue&type=Issues)

------
wolfgang42
What happened to the try/check error-handling proposal? In June it was
selected for inclusion in Go 1.14 [1], but then in the linked issue it seems
to have been declined in July. Where did it go? Why the sudden change of
heart?

[1]: [https://blog.golang.org/go2-next-
steps#TOC_2](https://blog.golang.org/go2-next-steps#TOC_2).

~~~
toxik
Go continues to impress me with its levelheaded design decisions, sadly I
don’t really have a use for it in my work.

~~~
tyri_kai_psomi
Since go makes it so easy to build a binary for most any platform, I think one
area anyone could introduce is it into their toolkits is by building small,
simple, purpose-built programs you can easily run on the command line to
perform a repetitive task.

------
fourseventy
I'm a bit confused by the new -static flag. I thought that by default go was
statically linked, what am i missing?

~~~
jpgvm
It's not quite that simple unfortunately. If you build a Go package with CGO
enabled then Go builds the binary dynamically linked to the system libc. (this
can be especially surprising if you believe go is "statically linked") However
when CGO is disabled it doesn't link against libc at all as Go has it's own
syscall layer etc.

It's not clear what this new -static flag will do, likely automatically setup
some of the linker static flags when compiling with CGO to statically link
other dependencies and perhaps libc itself.

~~~
sdegutis
> It's not quite that simple unfortunately.

This has been my experience with Go. First a promise of everything being much
simpler than the alternatives. Then, when we run into all sorts of confusion
and caveats, an unapologetic disclaimer about _why_ it's not simple and can't
be, with a long exposition about Go's own internal limitations and the trade-
offs they had to make.

~~~
Insanity
From my experience Go is simpler than other langs where it can be, and at
worst equally 'difficult' than the others. On average it's simpler.

------
dis-sys
the most exciting one for me is definitely the new escape analysis.

~~~
aaronbee
Even more exciting, this is already present in go1.13. I believe the author of
these slides made a mistake.

Here it is mentioned in go1.13 release notes:
[https://golang.org/doc/go1.13#compiler](https://golang.org/doc/go1.13#compiler)

And GitHub says the commit is present in go1.13:
[https://github.com/golang/go/commit/996a687ebbf81b26f81b41b8...](https://github.com/golang/go/commit/996a687ebbf81b26f81b41b8e62ef21d8b0826af)

~~~
agnivade
Yeah it is slightly misleading. The escape analysis rewrite was done in 1.13.
But work is now going on to remove the old escape analysis code.

------
xelekitry
So there are no changes to address the privacy issues[1] introduced in Go
1.13. The issue raised[2] about this seems to be stalled as well.

[1][https://proxy.golang.org/privacy](https://proxy.golang.org/privacy)
[2][https://github.com/golang/go/issues/33985](https://github.com/golang/go/issues/33985)

~~~
UncleEntity
Are those two links even related?

One talks about the privacy policy and the other is about private repos.

~~~
Zancarius
Yes, and I think the OP would've been better served by linking to the proxy
page rather than its privacy policy. I can understand why, however. Privacy,
proxies, and private repos are all inter-related but it might not be obvious
to people who don't use Go regularly or haven't followed the introduction of
proxies.

The problem is that if you don't set up your environment, set it up partially,
or set it up incorrectly, some information about private repositories will be
sent to Google[1]. One solution is to use the envvar GONOSUMDB (either set
from your shell's rc file or, preferably, from `go env`), thus instructing Go
which domains it should not validate against the checksum database. Some
individuals may not see this as an issue since private repos will fail to
download via the default GOPROXY (`go get` should revert to "direct" mode) and
nothing gets stored in the sumdb. However, Google does apparently log this
information internally, and that's where the privacy issue arises.

For additional protection, you can set GOPROXY to your own self-hosted server,
such as Athens, and configure it similarly so it'll reject such sumdb requests
with a 403 to catch clients using only GOPROXY. But, you still have to
remember to set GOPROXY (at a minimum), which means that if you or anyone in
your organization forgets this bit, you're back where you started and you're
_probably_ sending information about your private repos to Google. Again.

Since this relies on envvars or the Go env stored in ~/.config/go/env (as an
example) to set the behavior globally, you have to assume developers will
correctly configuring every system they use. The GitHub issue is mostly
centered on having a way to do this per-repository, and I honestly think that
would have been a better solution, even combined with the `go env` settings.

Personally, it doesn't bother me too much, because an external immutable
append-only log of commits in upstream packages will catch nefarious changes,
so I _think_ the benefits probably outweigh the privacy concerns until I see
an adequate argument countering this. Regardless, I still have my `go env` set
up to ignore my private repositories.

[1] The documentation says Google only logs the paths and doesn't publish them
for private repositories their proxy fails to download. I thought I read
somewhere that you can still use the sumdb for private repos, but it would
instead send something like a SHA256 sum of the path for additional privacy.
It might've been a proposal, and I can't find it now.

------
karmakaze
Language changes

    
    
      0. allow embedding overlapping interfaces
      1. len, cap to return untyped ints if constant
    

[0] [https://golang.org/issue/6977](https://golang.org/issue/6977) [1]
[https://github.com/golang/go/issues/31795](https://github.com/golang/go/issues/31795)

Major changes

    
    
      2. Remove SSLv3
      3. Make TLS 1.3 opt-out
      4. Automatically check and use vendored packages
      5. Low-cost defers via inline code
      6. Rewrite escape analysis
      7. Expose the runtime's hasher
      8. Add -static flag to go build
      9. Store package metadata in build cache
    

[2] [https://golang.org/issue/32716](https://golang.org/issue/32716) [3]
[https://golang.org/issue/30055](https://golang.org/issue/30055) [4]
[https://golang.org/issue/33848](https://golang.org/issue/33848) [5]
[https://golang.org/issue/34481](https://golang.org/issue/34481) [6]
[https://golang.org/issue/23109](https://golang.org/issue/23109) [7]
[https://golang.org/issue/28322](https://golang.org/issue/28322) [8]
[https://golang.org/issue/26492](https://golang.org/issue/26492) [9]
[https://golang.org/issue/31417](https://golang.org/issue/31417)

Minor changes

    
    
      [a] use go.sum hashes from all downloaded modules
      [b] fail tests that run os.Exit(0)
      [c] add testing.T.Deadline
      [d] add regexp.SubexpIndex
      [e] report failing test after a panic
      [f] Rewrite the compiler's rulegen
      [g] Change js mimetype to text/javascript
    

[a] [https://golang.org/issue/28802](https://golang.org/issue/28802) [b]
[https://golang.org/issue/29062](https://golang.org/issue/29062) [c]
[https://golang.org/issue/28135](https://golang.org/issue/28135) [d]
[https://golang.org/issue/32420](https://golang.org/issue/32420) [e]
[https://golang.org/issue/32121](https://golang.org/issue/32121) [f]
[https://golang.org/issue/30810](https://golang.org/issue/30810) [g]
[https://golang.org/issue/32351](https://golang.org/issue/32351)

------
pkaye
Do vscode/gopls work fine with modules now? I was getting sluggish behaviour
in the past.

~~~
geoah
They do work pretty nicely for the most part.

The only issue I'm still seeing is when having multiple go.mod files in the
same workspace. I end up having to split projects with sub-modules in multiple
workspaces in vscode and ignore the sub-modules on the main workspace.
[https://github.com/golang/go/issues/32394](https://github.com/golang/go/issues/32394)

------
mleonhard
Did they add min(int32,int32) and max(int32,int32) yet?

------
pjmlp
It could just as well be a bullet point list of urls.

What about providing a well thought out summary?

~~~
minxomat
Heh, I wish everyone would adopt the gold standard in changelogs: Noriyoshi
Shinoda's write-ups of changes in Postgres versions.

Example:
[https://h50146.www5.hpe.com/products/software/oe/linux/mains...](https://h50146.www5.hpe.com/products/software/oe/linux/mainstream/support/lcc/pdf/PostgreSQL_12_Beta1_New_Features_en_20190524-1.pdf)

Clear scope, introduction of new features and demonstrations with examples
(even of differences between versions)

~~~
grenoire
Christ, this is on the exact opposite extreme. I'm not sure if this is what I
would like to dig through for each big release; could be a _tad_ easier to
digest.

~~~
minxomat
I mean, I agree. But there's a toc and I usually skip to the sections relevant
to my use cases. The only people who should maybe read the entire thing are
(in this case) DBAs.

