Go 1.4+ Garbage Collection Plan and Roadmap
STW has to die.  I love that the goal is 10ms but in some environments the world has passed you by in 10ms and with STW you've timed out every single connection.<p>I want badly to fall in love with Go, I've enjoyed using it for some of my projects but I've seen serious challenges with more then four cores at very low latency (talking 9ms network RTT) and high QPS.. I cheated in one application and pinned the go process to each cpu and lied to Go and told it there was only one CPU but then you loose all the cool features of channels etc..  That helped some but a Nginx/LuaJIT implementation of the same solution still crushed it on the same box, identical workload.<p>It would be nice if we have to have STW to have it configurable, in some environments swapping memory for latency is fine and should be configurable.<p>The way Zing handles GC for Java acceleration is quite brilliant, not sure how much of that is open technology, but it would be cool to see the Go team reviewing what was learned in the process of maturing Java for low-latency high qps systems.