Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go 1.6 Release Candidate 1 is released

groups.google.com

Post reply on HN
Print view View original

11–20 of 23 posts

Re: Go 1.6 Release Candidate 1 is released

#11

Post by dsymonds »

smegel wrote: post #6
jfolkins wrote: post #5

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

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.

Re: Go 1.6 Release Candidate 1 is released

#12

Post by travjones »

nemothekid wrote: post #8

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

Re: Go 1.6 Release Candidate 1 is released

#13

Post by thewhitetulip »

BuckRogers wrote: post #3

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.

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!

Re: Go 1.6 Release Candidate 1 is released

#14

Post by jaytaylor »

smegel wrote: post #6
jfolkins wrote: post #5

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

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

Re: Go 1.6 Release Candidate 1 is released

#15

Post by jzelinskie »

thewhitetulip wrote: post #13
BuckRogers wrote: post #3

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.

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.

Re: Go 1.6 Release Candidate 1 is released

#16

Post by tagrun »

smegel wrote: post #6
jfolkins wrote: post #5

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

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

Re: Go 1.6 Release Candidate 1 is released

#17

Post by dgacmu »

travjones wrote: post #12
nemothekid wrote: post #8

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

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

Re: Go 1.6 Release Candidate 1 is released

#18

Post by Strom »

nemothekid wrote: post #7
smegel wrote: post #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.

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.

Re: Go 1.6 Release Candidate 1 is released

#19

Post by cryptos »

thewhitetulip wrote: post #13
BuckRogers wrote: post #3

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.

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!

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

Re: Go 1.6 Release Candidate 1 is released

#20

Post by aws_ls »

nemothekid wrote: post #8

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

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

Post reply on HN