My experience with trading systems led largely to the same conclusions.<p>You CAN write GC code that does very little collection, but you end up being allocation sensitive anyway, so you may as well write c++ code.<p>For instance I wrote some .NET where instead of logging with strings, I&#x27;d use StringBuilder and try to get some reuse. Problem is SB wasn&#x27;t written for that, and will allocate again if your new string gets too big. In the end it ended up being a pool of stringbuilders of various lengths. C++ would not have had this issue.<p>The problem with GC tends to be something alluded to in the article. When trading is brisk, a lot of data is coming in. So memory pressure is higher, leading to more GC. That&#x27;s exactly when you don&#x27;t want it. And debugging managed code I always find is more complicated than debugging C++. You need a whole suite of memory debuggers, all with their own idioms, and then it only really gives you a hint. With C++, you can valgrind et al where you can override new() and put in some accounting code. And it&#x27;s normally quite clear where you allocated.<p>You can also just tell the OS you&#x27;ll deal with memory yourself. Just get a big piece, and keep track of what&#x27;s what using various arenas and such constructs. That way you&#x27;re not even exposed to the variance in the OS allocation time (time to find space for a new object).