In case someone cares about these things, I compared the build times and the binary sizes for 1.9 vs 1.8.3 using the open source project we maintain [1]. This is on a 6-core i7-5280K:<p>Build time with 1.8.3:<p><pre><code> real 0m7.533s
user 0m36.913s
sys 0m2.856s
</code></pre>
Build time with 1.9:<p><pre><code> real 0m6.830s
user 0m35.082s
sys 0m2.384s
</code></pre>
Binary size:<p><pre><code> 1.8.3 : 19929736 bytes
1.9 : 20004424 bytes
</code></pre>
So... looks like the multi-threaded compilation indeed delivers better build times, but the binary size has increased slightly.<p>[1] You can git-clone and try yourself:
<a href="https://github.com/gravitational/teleport" rel="nofollow">https://github.com/gravitational/teleport</a>
t.Helper() is certainly going to be very useful. I often implement functions like:<p><pre><code> func testServer(t *testing.T, port int) {
...do stuff...
if err != nil { t.Fatalf("failed to start server: %+v", err) }
}
</code></pre>
similarly you can have<p><pre><code> func assertMapEquals(t *testing.T, a, b map[string]int)
</code></pre>
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.
In case you guys didn't know, there's multiple release party in different parts of the world: <a href="https://github.com/golang/cowg/blob/master/events/2017-08-go1.9-release-party.md" rel="nofollow">https://github.com/golang/cowg/blob/master/events/2017-08-go...</a><p>Come join if your near the area.
Nice can't wait to run some of our benchmarks against this. Go has the awesome property of always becoming a little bit faster every release. It's like your code becomes better without doing anything. Love it :)
In the release notes it says:<p><pre><code> "Mutex is now more fair."
</code></pre>
Source: <a href="https://golang.org/doc/go1.9#sync" rel="nofollow">https://golang.org/doc/go1.9#sync</a><p>Does anyone know what that means?
I am looking forward to<p>1. runtime/pprof package now include symbol information<p>2. Concurrent Map<p>3. Profiler Labels<p>4. database/sql reuse of cached statements<p>5. The os package now uses the internal runtime poller for file I/O.
Does anyone know of compile-time benchmarks spanning 1.4 through 1.9, along the lines of [1]?<p>I see there's (more) parallel compilation in 1.9 - so that should improve elapsed time (but not reduce cpu time) of compilation.<p>Would be nice to know if 1.9 is (still) on track catch up to/pass 1.4.<p>[1] <a href="https://dave.cheney.net/2016/11/19/go-1-8-toolchain-improvements" rel="nofollow">https://dave.cheney.net/2016/11/19/go-1-8-toolchain-improvem...</a>
I was looking forward to the fix for the dreaded Linux namespace handling problem: <a href="https://www.weave.works/blog/linux-namespaces-and-go-don-t-mix" rel="nofollow">https://www.weave.works/blog/linux-namespaces-and-go-don-t-m...</a> which kind of makes Go suck for many important container-related tasks. But apparently the effort has stalled... <a href="https://go-review.googlesource.com/c/go/+/46033" rel="nofollow">https://go-review.googlesource.com/c/go/+/46033</a>
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?<p>So basically it's designed for cases like 'I have N goroutines and each one owns 1/N keys'?
I'm wondering if we could abuse type alias to fake generics somehow? E.g.<p><pre><code> // file tree.go
type T = YourConcreteType
type TreeNode struct {
Value T
}
// rest of tree implementation
</code></pre>
Then you can just copy the file and replace YourConcreteType at the top and voila!<p>Seems simpler to use than the unicode hack here <a href="https://www.reddit.com/r/rust/comments/5penft/parallelizing_enjarify_in_go_and_rust/dcsgk7n/" rel="nofollow">https://www.reddit.com/r/rust/comments/5penft/parallelizing_...</a>