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

Go 1.9 is released

blog.golang.org

Post reply on HN
Print view View original

1–10 of 131 posts

Re: Go 1.9 is released

#2

Post by tmaly »

I am looking forward to

1. runtime/pprof package now include symbol information

2. Concurrent Map

3. Profiler Labels

4. database/sql reuse of cached statements

5. The os package now uses the internal runtime poller for file I/O.

Re: Go 1.9 is released

#3

Post by alphaalpha101 »

So this new concurrent map? Am I right in understanding it's designed for cases where you have a map shared between goroutines but where each goroutine essentially owns some subset of the keys in the map?

So basically it's designed for cases like 'I have N goroutines and each one owns 1/N keys'?

Re: Go 1.9 is released

#4

Post by alpb »

t.Helper() is certainly going to be very useful. I often implement functions like:

    func testServer(t *testing.T, port int) {
        ...do stuff...
        if err != nil { t.Fatalf("failed to start server: %+v", err) } 
    }
similarly you can have

    func assertMapEquals(t *testing.T, a, b map[string]int)
It lets you hide such helper methods from the test failure's stack trace (where t.Fatal is actually called), making test errors more readable.

Re: Go 1.9 is released

#5

Post by kraig »

alphaalpha101 wrote: post #3

So this new concurrent map? Am I right in understanding it's designed for cases where you have a map shared between goroutines but where each goroutine essentially owns some subset of the keys in the map? So basically it's designed for cases like 'I have N goroutines and each one owns 1/N keys'?

or you just have two or more goroutines that need to modify a map

Re: Go 1.9 is released

#6

Post by artursapek »

alphaalpha101 wrote: post #3

So this new concurrent map? Am I right in understanding it's designed for cases where you have a map shared between goroutines but where each goroutine essentially owns some subset of the keys in the map? So basically it's designed for cases like 'I have N goroutines and each one owns 1/N keys'?

It could just be one map shared by many goroutines, which normally causes a panic:

    fatal error: concurrent map writes

Re: Go 1.9 is released

#7

Post by e12e »

Does anyone know of compile-time benchmarks spanning 1.4 through 1.9, along the lines of [1]?

I see there's (more) parallel compilation in 1.9 - so that should improve elapsed time (but not reduce cpu time) of compilation.

Would be nice to know if 1.9 is (still) on track catch up to/pass 1.4.

[1] https://dave.cheney.net/2016/11/19/go-1-8-toolchain-improvem...

Re: Go 1.9 is released

#8

Post by vanderZwan »

alphaalpha101 wrote: post #3

So this new concurrent map? Am I right in understanding it's designed for cases where you have a map shared between goroutines but where each goroutine essentially owns some subset of the keys in the map? So basically it's designed for cases like 'I have N goroutines and each one owns 1/N keys'?

> each goroutine essentially owns some subset of the keys in the map

With those constraints, why not create a small map for each goroutine at that point, and merge the maps afterwards?

Re: Go 1.9 is released

#10

Post by freecodyx »

artursapek wrote: post #6
alphaalpha101 wrote: post #3

So this new concurrent map? Am I right in understanding it's designed for cases where you have a map shared between goroutines but where each goroutine essentially owns some subset of the keys in the map? So basically it's designed for cases like 'I have N goroutines and each one owns 1/N keys'?

It could just be one map shared by many goroutines, which normally causes a panic: fatal error: concurrent map writes

i am dealing with this problem right now. also i have a big problem with deepclone,

I did a big rewrite of a current project, and clearly it was badly designed :(

Post reply on HN