5 ms·

Go 1.6 Release Candidate 1 is released

87 points by pella 11y ago

travjones 11y ago
Awesome! Thanks, Go Team! If you're interested in meeting Go devs in your area next month find a 1.6 release party near you: https://github.com/golang/go/wiki/Go-1.6-release-party https://github.com/golang/go/wiki/Go-1.6-release-party. Unofficial theme song: https://www.youtube.com/watch?v=xNat6iJB5So https://www.youtube.com/watch?v=xNat6iJB5So
BuckRogers 11y ago
I've been testing out Go for a while now and outside of deployment, the CPU performance and GC tuning that has come with new versions has been a really, really great perk over time. No code change, no breakage, just constant free performance.
- iends 11y ago
  This is one of the reasons I'm looking forward to 1.7 and new SSA (which was cut from 1.6). (see branch dev.ssa and the proposal here: https://docs.google.com/document/d/1szwabPJJc4J-igUZU4ZKprOrNRNJug2JPD8OYi3i1K0/edit#heading=h.ywtmh4qacfis https://docs.google.com/document/d/1szwabPJJc4J-igUZU4ZKprOr...). It should give a nice speed increase and binary size decrease in your programs for free!
- thewhitetulip 11y ago
  We can see the way Go solves this problem without breaking your code, a way not taken these days where not so well designed solutions break when we have to upgrade. Python 2 and python 3, angular 1 and angular 2. I guess this is the difference between a pet project gone wild and a well thought and well designed programming language designed to make the process of building applications faster and better!
  - jzelinskie 11y ago
    You are conflating major and minor versions of software. Python 2 & 3 and Angular 1 & 2 are major versions that have forward declared breaking changes. If/When Go 2 is released, it will contain language breaking changes.
  - cryptos 11y ago
    One could see it from the other side: code sticks to its design weaknesses (at least for now).
  - sriram_malhar 11y ago
    Go is too young, and has extremely small adoption compared to Python, C, C++, Java. When a language has been around for so long that entire idioms have changed (functional in, object out, reactive in, iteration out etc.), the usage landscape has changed (from desktop scripts up to cloud-scale and down to mobile-app scale), it is natural for the language to have to adapt. The hope is that Go will have enough adoption to require breaking changes!
smegel 11y ago
> As always, if one goroutine is writing to a map, no other goroutine should be reading or writing the map concurrently. What if you are writing to a value in the map? Surely that is safe to do concurrently with other processes reading at least.
- jfolkins 11y ago
  >> As always, if one goroutine is writing to a map, no other goroutine should be reading or writing the map concurrently. > What if you are writing to a value in the map? Surely that is safe to do concurrently with other processes reading at least. Nope. You need to protect your state by communicating with channels or using a lock.
  - smegel 11y ago
    > You need to protect your state by communicating with channels or using a lock. But what are you protecting? Setting a value will not cause a map rebalance, and so long as you are just setting a new value (not incrementing or like) it should be an atomic operation. Locking is really slow, and if you can find safe ways to avoid it, it can be a good thing.
    - timtadh 11y ago
      Another thread could 1) write to the same key. 2) cause a table expansion (or a shrink) which rehashes the whole table (in most implementations). Either case will cause a difficult to diagnose bug. Use a lock or communicate with channels instead. There may be other subtle things which can get corrupted under concurrent use. The map type in Go has never been implemented in a thread safe fashion so if you try and use it as such you will be in for a bad time.
    - dsymonds 11y ago
      There's nothing specified that setting a value won't cause a map rebalance or rehash. The implementation is allowed to change things under the hood.
    - 11y ago
nemothekid 11y ago
Interesting thing about this release is baked in support for Http/2. On the client side, http/2 is awesome for services like spiders that support it because the memory usage and performance is a lot better. And you don't even have to do anything to take advantage other than upgrade to go 1.6
- travjones 11y ago
  >> And you don't even have to do anything to take advantage other than upgrade to go 1.6 I know, right! That's what's sick. Even upgrading to the latest version of go is easy: "To remove an existing Go installation from your system delete the go directory. This is usually /usr/local/go." Then install the latest...
  - dgacmu 11y ago
    gvm is also worthwhile, particularly on ubuntu, and particularly if you want to test out the RC without fully committing to it. https://github.com/moovweb/gvm https://github.com/moovweb/gvm
    - fortytw2 11y ago
      if you want 20,000 lines of shell script to manage one of the simplest to install languages out there, sure. :/
  - Sfi81 11y ago
    Probably commenting too late but I find it a lot simpler to just compile from source. After you're initially setup (you need a go1.4 installation in your homedir), you just pull the latest repo updates, checkout the release tag and run all.bash or all.bat each time. This also gives you cross-compilation and ability to contribute bug fixes.
- aws_ls 11y ago
  The HTTP2 support in Go 1.6 is very exciting, on the server side as well. I have been looking forward to it. On a related note, I found this HTTP2 whitepaper by Nginx team, educating and very informative. https://www.nginx.com/wp-content/uploads/2015/09/NGINX_HTTP2_White_Paper_v4.pdf https://www.nginx.com/wp-content/uploads/2015/09/NGINX_HTTP2...

87 points by pella 11y ago

Awesome! Thanks, Go Team! If you're interested in meeting Go devs in your area next month find a 1.6 release party near you: https://github.com/golang/go/wiki/Go-1.6-release-party https://github.com/golang/go/wiki/Go-1.6-release-party. Unofficial theme song: https://www.youtube.com/watch?v=xNat6iJB5So https://www.youtube.com/watch?v=xNat6iJB5So

BuckRogers 11y ago

I've been testing out Go for a while now and outside of deployment, the CPU performance and GC tuning that has come with new versions has been a really, really great perk over time. No code change, no breakage, just constant free performance.

iends 11y ago
This is one of the reasons I'm looking forward to 1.7 and new SSA (which was cut from 1.6). (see branch dev.ssa and the proposal here: https://docs.google.com/document/d/1szwabPJJc4J-igUZU4ZKprOrNRNJug2JPD8OYi3i1K0/edit#heading=h.ywtmh4qacfis https://docs.google.com/document/d/1szwabPJJc4J-igUZU4ZKprOr...). It should give a nice speed increase and binary size decrease in your programs for free!
thewhitetulip 11y ago
We can see the way Go solves this problem without breaking your code, a way not taken these days where not so well designed solutions break when we have to upgrade. Python 2 and python 3, angular 1 and angular 2. I guess this is the difference between a pet project gone wild and a well thought and well designed programming language designed to make the process of building applications faster and better!
- jzelinskie 11y ago
  You are conflating major and minor versions of software. Python 2 & 3 and Angular 1 & 2 are major versions that have forward declared breaking changes. If/When Go 2 is released, it will contain language breaking changes.
- cryptos 11y ago
  One could see it from the other side: code sticks to its design weaknesses (at least for now).
- sriram_malhar 11y ago
  Go is too young, and has extremely small adoption compared to Python, C, C++, Java. When a language has been around for so long that entire idioms have changed (functional in, object out, reactive in, iteration out etc.), the usage landscape has changed (from desktop scripts up to cloud-scale and down to mobile-app scale), it is natural for the language to have to adapt. The hope is that Go will have enough adoption to require breaking changes!

smegel 11y ago

> As always, if one goroutine is writing to a map, no other goroutine should be reading or writing the map concurrently. What if you are writing to a value in the map? Surely that is safe to do concurrently with other processes reading at least.

jfolkins 11y ago
>> As always, if one goroutine is writing to a map, no other goroutine should be reading or writing the map concurrently. > What if you are writing to a value in the map? Surely that is safe to do concurrently with other processes reading at least. Nope. You need to protect your state by communicating with channels or using a lock.
- smegel 11y ago
  > You need to protect your state by communicating with channels or using a lock. But what are you protecting? Setting a value will not cause a map rebalance, and so long as you are just setting a new value (not incrementing or like) it should be an atomic operation. Locking is really slow, and if you can find safe ways to avoid it, it can be a good thing.
  - timtadh 11y ago
    Another thread could 1) write to the same key. 2) cause a table expansion (or a shrink) which rehashes the whole table (in most implementations). Either case will cause a difficult to diagnose bug. Use a lock or communicate with channels instead. There may be other subtle things which can get corrupted under concurrent use. The map type in Go has never been implemented in a thread safe fashion so if you try and use it as such you will be in for a bad time.
  - dsymonds 11y ago
    There's nothing specified that setting a value won't cause a map rebalance or rehash. The implementation is allowed to change things under the hood.
  - 11y ago

nemothekid 11y ago

Interesting thing about this release is baked in support for Http/2. On the client side, http/2 is awesome for services like spiders that support it because the memory usage and performance is a lot better. And you don't even have to do anything to take advantage other than upgrade to go 1.6

travjones 11y ago
>> And you don't even have to do anything to take advantage other than upgrade to go 1.6 I know, right! That's what's sick. Even upgrading to the latest version of go is easy: "To remove an existing Go installation from your system delete the go directory. This is usually /usr/local/go." Then install the latest...
- dgacmu 11y ago
  gvm is also worthwhile, particularly on ubuntu, and particularly if you want to test out the RC without fully committing to it. https://github.com/moovweb/gvm https://github.com/moovweb/gvm
  - fortytw2 11y ago
    if you want 20,000 lines of shell script to manage one of the simplest to install languages out there, sure. :/
- Sfi81 11y ago
  Probably commenting too late but I find it a lot simpler to just compile from source. After you're initially setup (you need a go1.4 installation in your homedir), you just pull the latest repo updates, checkout the release tag and run all.bash or all.bat each time. This also gives you cross-compilation and ability to contribute bug fixes.
aws_ls 11y ago
The HTTP2 support in Go 1.6 is very exciting, on the server side as well. I have been looking forward to it. On a related note, I found this HTTP2 whitepaper by Nginx team, educating and very informative. https://www.nginx.com/wp-content/uploads/2015/09/NGINX_HTTP2_White_Paper_v4.pdf https://www.nginx.com/wp-content/uploads/2015/09/NGINX_HTTP2...