So You Wanna Go Fast?

&gt; When performance really matters, you have to start thinking at the hardware level. Formula One driver Jackie Stewart is famous for once saying, “You don’t have to be an engineer to be be a racing driver, but you do have to have mechanical sympathy.”<p>If you are going to reference that quote, talk about ring buffers, and false sharing. I think it behooves you to credit Martin Thompson or LMAX in some way. That is a near verbatim quote from the Disruptor papers.

Replacing a channel with a ring buffer that spins (and uses runtime.Gosched every 1000 failed attempts) is really bad general advice. The other advice is similar.<p>It may be a good idea for very specific use cases and might have served the author well, but the channel will scale far better in the general case and suffer from have less degenerative cases.<p>Looking at artificial benchmarks is very misleading. If you take the ring buffer linked in the article and throw 1000 producers and one consumer at it, it will completely and utterly fall over. Channels on the other hand, will behave just fine.<p>My take: use the language primitives unless you really know what you&#x27;re doing. Then you should also know that it&#x27;s not a general optimization.

&gt;Ultimately, you hit the ceiling of what you can do with it, and you have to migrate off (if you’re a business that is trying to grow, anyway).<p>I read this post and the one that was linked to and I still don&#x27;t understand what the problem was that they faced with Google App Engine. A few specifics would have been helpful.

My favourite bit of this article was where they pad the struct to move each field onto separate cpu cache lines and see a 15% speed increase.

This article became hilarious when I reached &quot;App Engine was stateless, so the natural tendency once you&#x27;re off it was to make everything stateful. And we did.&quot; Oh my.

Seriously, if you care about lock-free algorithms, zero-cost abstractions, control of memory management and avoiding false sharing, why use Go in the first place? C&#x2F;C++ and Rust are much more practical choices, even Java has mature concurrent data structures. IMHO, Go is a sensible choice to achieve 80&#x2F;100 raw performance. Beyond that, Go is just not the right tool.

It seems like if you&#x27;re going to care about performance this much you might want to use a language that doesn&#x27;t discriminate between heap and stack.<p>Sure you can do all these gymnastics, but why not use tools that were built to do this from the start like Rust and C++?

If you&#x27;re not first, you&#x27;re last.

OK, this is completely off topic, but this sentence start from the article jumped out at me:<p><i>It’s honestly a good question to ask</i><p>Why is it that so many people now start sentences with some variation of &quot;honestly&quot;? I see it in comments here on HN all the time, and in lots of tech blog posts.<p>Is there a new paper out on how this is effective rhetoric? Is it a regional tick I haven&#x27;t figured out yet?<p>Honestly, I find it depressing that so many people feel the need to preface what they are saying with a declaration that they are not, in fact, lying to us.