
Go 1.6 Release Candidate 1 is released - pella
https://groups.google.com/forum/#!topic/golang-nuts/4iqU__h7skQ
======
BuckRogers
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.

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

------
nemothekid
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
>> 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
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
if you want 20,000 lines of shell script to manage one of the simplest to
install languages out there, sure. :/

------
travjones
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)

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

