4 ms·

Go 1.7 freeze announced

91 points by vruiz 10y ago

rdegges 10y ago
I think this is a major step in the right direction for the Go team. Shipping on time and being ruthless with what gets into a release will only help Go in the long-term. For what it's worth, I think the entire Go core team has done an awesome job with releases, and pushing forward for improvements.
- dward 10y ago
  Don't they do this every release?
  - deleted 10y ago
    [deleted]
  - jshen 10y ago
    From the article/link: As noted in past emails to golang-dev and on golang.org/wiki/Go-Release-Cycle, the constraints above are stricter than in past cycles. An explicit goal is to ship the first beta on time, by May 31, instead of many weeks late as has been our past practice. (If the past pattern held, this release's first beta would be seven weeks late, or one week before the scheduled release date.)
- ivoras 10y ago
  Ok, so what strategies do people use for coping with their development / build environments (even entire languages and stdlibs) changing every 6 months? Is stability out of the window?
  - burntsushi 10y ago
    Code written that compiles on Go 1.0 should still compile with Go 1.7.
  - AYBABTME 10y ago
    Bump Go, fix bugs that were there but are now exposed by improvements to the runtime/race detectors, carry on with life.
  - deleted 10y ago
    [deleted]
  - mattetti 10y ago
    Stability increases, in our case, we just update Go on our CI and we get smaller binaries, better performance as updates come in. The code is always backward compatible so our code always compile. We obviously make sure our test suite passes and don't see any regressions. It was nice to get http/2 for free in a recent update, especially with cloudFlare now supporting http/2 push.
  - enneff 10y ago
    https://golang.org/doc/go1compat https://golang.org/doc/go1compat
  - randomdata 10y ago
    Go 1.x is deemed stable[1]. [1] https://golang.org/doc/go1compat https://golang.org/doc/go1compat
  - dgacmu 10y ago
    Others already noted - it's backwards-compatible. But it's actually even a bit easier than that for an all-Go project. On Ubuntu, the easiest way to have go installed is to use gvm ( https://github.com/moovweb/gvm https://github.com/moovweb/gvm ). Which means you do something like: $ gvm install go1.7 $ gvm use go1.7 $ go build myproj Errors? Fix them - and in the meantime, just switch back: $ gvm use go1.6 $ go build myproj It's impressively painless. I went from go1.4 to 1.6 without having to change a single line of code -- but the 'go vet' tool got better, so when I re-ran it, it pointed out a few things that I then fixed. The compile didn't break without them, notably.
  - manacit 10y ago
    I'll echo what a lot of people are saying, with some caveats. The Go language spec hasn't changed since 1.0 -- that means that, by and large, code written in the days of 1.0 will still compile in 1.6 (and should compile in 1.7). Of course, reality is often different. We have a very large Go monorepo at work, and we've run into almost every breaking-but-not-spec-changing change in the language since 1.4. We've had subtle changes in behavior cause panics in production, code that used CGO to stop compiling, third party libraries tripping the race detector when GOMAXPROCS=NUMCPU was introduced by default, etc. The majority of changes/fixes have been pretty small, and I'd say it takes about a day of man-hours every six months to get us on the next release, which is a drop in the bucket.
    - enneff 10y ago
      I'd like to note that all the issues you encountered are because newer versions of Go have exposed issues in your application code and dependencies (with the possible exception of the new cgo pointer passing restrictions).
      - manacit 10y ago
        Totally - I hope no one read it as anything otherwise. There's a wide chasm of "change" that can happen without the spec changing, was my main point. We run a lot of static analysis on our code, which includes things like `go vet`, `go fmt`, etc. Between point releases, there's no guarantee that those tools aren't changing/adding tests and functionality, which has been one of the bigger sources in our work required to upgrade. All in all, it really is a painless and usually positive procedure - a ton of those fixes were subtly broken things who's behavior has been clarified. I think of it as a positive thing.
kevinmgranger 10y ago
Is there a work-in-progress changelog of what we can expect to see in 1.7? I couldn't find one.
- 4ad 10y ago
  Very incomplete: https://tip.golang.org/doc/go1.7.txt https://tip.golang.org/doc/go1.7.txt
  - dguaraglia 10y ago
    This looks sweet: runtime: support symbolic backtrace of C code in a cgo crash (CL 17761)
  - weitzj 10y ago
    Now what does that mean? What does Fortran have to do with Go? | add support for Fortran (CL 19670, CL 4114)
    - 4ad 10y ago
      You can now call Fortran code through cgo, from Go.
- 0xmohit 10y ago
  There has been significant work on performance and toolchain improvement. See http://dave.cheney.net/2016/04/02/go-1-7-toolchain-improvements http://dave.cheney.net/2016/04/02/go-1-7-toolchain-improveme... for information.
- mattetti 10y ago
  the main changes are related to the SSA compiler backend and smaller binary files. 1.7 should also better support binary only packages (so vendors can sell compiled packages without providing sources, it kinda works right now but was hacky/buggy).
sig_chld_mike 10y ago
Can we make a community list about topics that we can criticize the Go core team for and also add a priority ranking for topics that deserve the most scorn?
- deleted 10y ago
  [deleted]

91 points by vruiz 10y ago

I think this is a major step in the right direction for the Go team. Shipping on time and being ruthless with what gets into a release will only help Go in the long-term. For what it's worth, I think the entire Go core team has done an awesome job with releases, and pushing forward for improvements.

dward 10y ago
Don't they do this every release?
- deleted 10y ago
  [deleted]
- jshen 10y ago
  From the article/link: As noted in past emails to golang-dev and on golang.org/wiki/Go-Release-Cycle, the constraints above are stricter than in past cycles. An explicit goal is to ship the first beta on time, by May 31, instead of many weeks late as has been our past practice. (If the past pattern held, this release's first beta would be seven weeks late, or one week before the scheduled release date.)
ivoras 10y ago
Ok, so what strategies do people use for coping with their development / build environments (even entire languages and stdlibs) changing every 6 months? Is stability out of the window?
- burntsushi 10y ago
  Code written that compiles on Go 1.0 should still compile with Go 1.7.
- AYBABTME 10y ago
  Bump Go, fix bugs that were there but are now exposed by improvements to the runtime/race detectors, carry on with life.
- deleted 10y ago
  [deleted]
- mattetti 10y ago
  Stability increases, in our case, we just update Go on our CI and we get smaller binaries, better performance as updates come in. The code is always backward compatible so our code always compile. We obviously make sure our test suite passes and don't see any regressions. It was nice to get http/2 for free in a recent update, especially with cloudFlare now supporting http/2 push.
- enneff 10y ago
  https://golang.org/doc/go1compat https://golang.org/doc/go1compat
- randomdata 10y ago
  Go 1.x is deemed stable[1]. [1] https://golang.org/doc/go1compat https://golang.org/doc/go1compat
- dgacmu 10y ago
  Others already noted - it's backwards-compatible. But it's actually even a bit easier than that for an all-Go project. On Ubuntu, the easiest way to have go installed is to use gvm ( https://github.com/moovweb/gvm https://github.com/moovweb/gvm ). Which means you do something like: $ gvm install go1.7 $ gvm use go1.7 $ go build myproj Errors? Fix them - and in the meantime, just switch back: $ gvm use go1.6 $ go build myproj It's impressively painless. I went from go1.4 to 1.6 without having to change a single line of code -- but the 'go vet' tool got better, so when I re-ran it, it pointed out a few things that I then fixed. The compile didn't break without them, notably.
- manacit 10y ago
  I'll echo what a lot of people are saying, with some caveats. The Go language spec hasn't changed since 1.0 -- that means that, by and large, code written in the days of 1.0 will still compile in 1.6 (and should compile in 1.7). Of course, reality is often different. We have a very large Go monorepo at work, and we've run into almost every breaking-but-not-spec-changing change in the language since 1.4. We've had subtle changes in behavior cause panics in production, code that used CGO to stop compiling, third party libraries tripping the race detector when GOMAXPROCS=NUMCPU was introduced by default, etc. The majority of changes/fixes have been pretty small, and I'd say it takes about a day of man-hours every six months to get us on the next release, which is a drop in the bucket.
  - enneff 10y ago
    I'd like to note that all the issues you encountered are because newer versions of Go have exposed issues in your application code and dependencies (with the possible exception of the new cgo pointer passing restrictions).
    - manacit 10y ago
      Totally - I hope no one read it as anything otherwise. There's a wide chasm of "change" that can happen without the spec changing, was my main point. We run a lot of static analysis on our code, which includes things like `go vet`, `go fmt`, etc. Between point releases, there's no guarantee that those tools aren't changing/adding tests and functionality, which has been one of the bigger sources in our work required to upgrade. All in all, it really is a painless and usually positive procedure - a ton of those fixes were subtly broken things who's behavior has been clarified. I think of it as a positive thing.

kevinmgranger 10y ago

Is there a work-in-progress changelog of what we can expect to see in 1.7? I couldn't find one.

4ad 10y ago
Very incomplete: https://tip.golang.org/doc/go1.7.txt https://tip.golang.org/doc/go1.7.txt
- dguaraglia 10y ago
  This looks sweet: runtime: support symbolic backtrace of C code in a cgo crash (CL 17761)
- weitzj 10y ago
  Now what does that mean? What does Fortran have to do with Go? | add support for Fortran (CL 19670, CL 4114)
  - 4ad 10y ago
    You can now call Fortran code through cgo, from Go.
0xmohit 10y ago
There has been significant work on performance and toolchain improvement. See http://dave.cheney.net/2016/04/02/go-1-7-toolchain-improvements http://dave.cheney.net/2016/04/02/go-1-7-toolchain-improveme... for information.
mattetti 10y ago
the main changes are related to the SSA compiler backend and smaller binary files. 1.7 should also better support binary only packages (so vendors can sell compiled packages without providing sources, it kinda works right now but was hacky/buggy).

sig_chld_mike 10y ago

Can we make a community list about topics that we can criticize the Go core team for and also add a priority ranking for topics that deserve the most scorn?

deleted 10y ago
[deleted]