What's Coming in Go 1.14 [slides] | Hacker News Reader

What's Coming in Go 1.14 [slides]

docs.google.com

107 pointsngaut40 comments

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.

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

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

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

[2] https://github.com/search?q=golang+%22checksum+mismatch%22+i...

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.

It was tried, discussed and abandoned: https://youtu.be/kNHo788oO5Y?t=1026

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

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.

I don’t think the majority actually want this to be part of go

Vocal minority, perhaps.

They got carried away with their own cleverness and forgot about the real world, shit happens.

The good news is they realized and and realigned with the community, which is awesome.

Here was the previous discussion when that was abandoned on July 16:

https://news.ycombinator.com/item?id=20454966

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

Go can link against c libraries. This would make that static as well.

Simple Go binaries do tend to be statically linked, which is where I think the confusion comes from.

The most common source of dynamic linking is cgo, since CGO_ENABLED=1 is the default when not cross-compiling. For example, importing os/user will dynamically link against libc, unless you disable cgo or force statically linking with libc.

See https://github.com/golang/go/issues/26492 for more details. I think the purpose of the flag will be to force static linking in all edge cases, while not disabling cgo explicitly.

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.

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

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.

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

Does it offer any user visible improvements or is it only a compiler internal improvement?

It might lead to fewer allocations in complex programs, as the compiler is able to put more in the stack under some edge cases.

Yeah, useful for teams that want to use pointers everywhere and disregard escape analysis xD

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

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

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.

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 [2]https://github.com/golang/go/issues/33985

Are those two links even related?

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

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.

Language changes

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

[0] https://golang.org/issue/6977 [1] 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 [3] https://golang.org/issue/30055 [4] https://golang.org/issue/33848 [5] https://golang.org/issue/34481 [6] https://golang.org/issue/23109 [7] https://golang.org/issue/28322 [8] https://golang.org/issue/26492 [9] 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 [b] https://golang.org/issue/29062 [c] https://golang.org/issue/28135 [d] https://golang.org/issue/32420 [e] https://golang.org/issue/32121 [f] https://golang.org/issue/30810 [g] https://golang.org/issue/32351

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

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

Recent discussion: https://old.reddit.com/r/golang/comments/ddf721/vscode_is_a_...

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

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

What about providing a well thought out summary?

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

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

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.

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.

Chapter 2 (Chapter 1 is "About This Document") is "New Features Summary".

(warning: pdf link)

I think the laravel upgrade guide is better, you see what might actually break or cause unintended behavior and there's a release notes page with a list of new stuff you can choose to use.

https://laravel.com/docs/6.x/upgrade

Original link is not changelog, but slides from the meetup presentation. Typical Go changelog is here: https://golang.org/doc/go1.13

These are the slides from a talk; I didn't spend the extra time to change the format or write down what I explained.

After all, I didn't post them here, someone else did :)

I personally think it's best to just follow the links if the title sounds interesting to you.

Fair enough.

I did follow the links, however it is a bit tedious to then make a picture from the endless mountain of comments on each issue, hence the remark.

Reply on news.ycombinator.com