Go 1.6 Release Candidate 1 is released
groups.google.com
Go 1.6 Release Candidate 1 is released
1–10 of 23 posts
Re: Go 1.6 Release Candidate 1 is released
#2Awesome! 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.
Unofficial theme song: https://www.youtube.com/watch?v=xNat6iJB5So
Re: Go 1.6 Release Candidate 1 is released
#3I'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.
Re: Go 1.6 Release Candidate 1 is released
#4> 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.
Re: Go 1.6 Release Candidate 1 is released
#5> 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.
>> 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.
Re: Go 1.6 Release Candidate 1 is released
#6> 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.
>> 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.
> 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.
Re: Go 1.6 Release Candidate 1 is released
#7> 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.
Only if you do something like:
ml.Lock()
v := m["key"] // maybe m is something like map[string]*MyValue
ml.Unlock()
v.foo = "bar" // m["key"].foo is now bar, because m["key"] both point to the same objectRe: Go 1.6 Release Candidate 1 is released
#8Interesting 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
Re: Go 1.6 Release Candidate 1 is released
#9I'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.
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-igUZU4ZKprOr...).
It should give a nice speed increase and binary size decrease in your programs for free!
Re: Go 1.6 Release Candidate 1 is released
#10Earlier quoted context omitted.
>> 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.
> 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.
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.