Yes, I have. We used go in a system that had to keep track of essentially large hashes containing popularity / scoring information, in addition to what were effectively routing tables, and ran into >500ms pauses.

At scale, it seemed the largest part of the complexity of go was manipulating data structures and code to avoid gc pauses. With sufficient work we may have been able to decrease the pauses sufficiently, but we also ran into raw request per second numbers that were lower than we liked.

The direction we have taken was to switch to C++ for this application. Having said that, the gc pauses were the primary reason for the change.

If it's possible, and you're interested in trying, it would be interesting to pull that code out and try it again with Go 1.5, if it's easy.

If you've got a C++ solution, I would not suggest under any circumstances short of Go suddenly and frankly mysteriously blowing the doors off of C++ that you switch... I'm just saying it would be an interesting comparison.

I'll be recommending we try it in a lab with go 1.5, absolutely.

Why didn't you just use Java? Hotspot has been optimized for over a decade to make (among other things) gc pauses as manageable as possible. And there are other runtimes (http://www.azulsystems.com/) specifically optimized for low latency. The poor quality of Go's GC were never a secret.

Ah, too bad. Do you know what sort of heap sizes you got those pauses at?

About half a gig resident memory.

So Go's GC spent 1ms per MB?

According to this graph: https://pbs.twimg.com/media/CJatKFQUkAE5qcR.png:large

It's about 0.3ms per MB, so 1ms isn't that different.

x86 or x86_64?

x86_64

For many applications, like web backends that may have previously been written in Ruby, Python, or JavaScript, the garbage collector was not noticeable at all. Improvements to the garbage collector target apps that previously would have been written in C with manual memory management, as mentioned in the talk. Not all apps need to be written in C obviously, but this will help bring Go's concurrency primitives to places where the GC was previously a deal breaker, such as eggnet's program.

That's exactly the awkward ground Go is in and why I stopped using it. It's not really necessary for any company's web backend I've worked on, the existing in Ruby/Python/JS works fine. Yet it can't compete with the other stuff out there, Rust, C(++), Erlang or soon Swift 2.0.

Though admittedly, some of these have a dismal concurrency story so I got to hand Go credit where it deserves.