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.

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!

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!

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.

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!

One could see it from the other side: code sticks to its design weaknesses (at least for now).

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

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

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.

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

if you want 20,000 lines of shell script to manage one of the simplest to install languages out there, sure. :/

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

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.

Unofficial theme song: https://www.youtube.com/watch?v=xNat6iJB5So

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

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.

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.

Locks are actually really cheap in many instances; mutexes can Lock and Unlock millions of times per second as long as contention is low.

> so long as you are just setting a new value

The hash map first needs to determine whether it already has a value with such a key or not, which requires some checking that typically involves many instructions and is not atomic. And to determine that, you at least need a read-lock.

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 object

If you ever intend to read that v.foo value in another goroutine, then that edit needs to be before freeing the lock as well.