4 ms·

Congrats, this is a huge release. We had some weird corruption of memory issues late in the 1.5RC cycle. It's possible that https://github.com/golang/go/commi

Congrats, this is a huge release. We had some weird corruption of memory issues late in the 1.5RC cycle. It's possible that https://github.com/golang/go/commit/3ae17043f7f29f0d745aa35b340f8cab80219068 https://github.com/golang/go/commit/3ae17043f7f29f0d745aa35b... fixed it, but each test for bisection cost us 4 hours, and the bug didn't always show. (When it did show, it definitely showed without -race mode on, contrary to the comments in the patch) Anyway, if you have a large memory usage highly concurrent go app, I would still tread lightly and carefully with this release; we spent a goodly amount of time blaming our own code before realizing that 1.4.2 did not exhibit the problem.

rsc 11y ago
To be fair, this is true of pretty much any major release of a new piece of software: tread lightly and test carefully before deploying to production. The new GC, default GOMAXPROCS > 1, and changes to the scheduler may well expose latent bugs in code that worked fine in Go 1.4.
- vessenes 11y ago
  Totally. We've been mostly running tip for some time, and sending in bug reports when we can be useful, overall a big win for us, but not without its risks. :) Honestly, I could have seen rebranding 1.5 to 2.0; there are major under the hood changes you guys have made.
  - rsc 11y ago
    I can see that, and I've been idly wondering over the past few days what the largest N will be for Go 1.N. The contrast with most version numbering, however, is that we've defined a meaning for Go 2: it breaks all your Go 1 programs. Being a Go 1.X release is actually a stronger statement about how your code will behave.
    - andrewchambers 11y ago
      Waiting for the confusion when Go1 2.0 is released :). Or are you thinking of 1.10?
      - tagrun 11y ago
        "Go1 2.0" is meaningless, Go X refers to Go X.Y.Z. Many FOSS programs treat X, Y and Z as numbers rather than digits, and increment X when there is a breaking change in the API or some serious restructuring/change (this is starting to change, recently we see programs incrementing major version periodically [most remarkably, Linux, Firefox, GCC have jumped on this bandwagon], these days only FOSS libraries are seriously sticking to that.) so yeah, it's probably going to be 1.10 and so on.
  - duaneb 11y ago
    I would hope that 1.5 to 2.0 would have some semantic changes to the language as opposed to just implementation tooling. I've learned not to even ask about type improvements. :(
    - deleted 11y ago
      [deleted]

rsc 11y ago

To be fair, this is true of pretty much any major release of a new piece of software: tread lightly and test carefully before deploying to production. The new GC, default GOMAXPROCS > 1, and changes to the scheduler may well expose latent bugs in code that worked fine in Go 1.4.

vessenes 11y ago
Totally. We've been mostly running tip for some time, and sending in bug reports when we can be useful, overall a big win for us, but not without its risks. :) Honestly, I could have seen rebranding 1.5 to 2.0; there are major under the hood changes you guys have made.
- rsc 11y ago
  I can see that, and I've been idly wondering over the past few days what the largest N will be for Go 1.N. The contrast with most version numbering, however, is that we've defined a meaning for Go 2: it breaks all your Go 1 programs. Being a Go 1.X release is actually a stronger statement about how your code will behave.
  - andrewchambers 11y ago
    Waiting for the confusion when Go1 2.0 is released :). Or are you thinking of 1.10?
    - tagrun 11y ago
      "Go1 2.0" is meaningless, Go X refers to Go X.Y.Z. Many FOSS programs treat X, Y and Z as numbers rather than digits, and increment X when there is a breaking change in the API or some serious restructuring/change (this is starting to change, recently we see programs incrementing major version periodically [most remarkably, Linux, Firefox, GCC have jumped on this bandwagon], these days only FOSS libraries are seriously sticking to that.) so yeah, it's probably going to be 1.10 and so on.
- duaneb 11y ago
  I would hope that 1.5 to 2.0 would have some semantic changes to the language as opposed to just implementation tooling. I've learned not to even ask about type improvements. :(
  - deleted 11y ago
    [deleted]