just scanning through that article as well... i was already aware of this issue with Go's GC and it isn't fair to say it's a forever problem either, the smarts of the GC get better and better over time, and there is ways to bypass it, this is the thing, if you write code as though you are going to 100% entrust the reuse of memory in this way to the GC, you will have trouble at scale, the simple fact is that this degree of control requires you to bypass the GC and use free lists and write your code with the thought in mind that later you may need to take the memory reuse out of the hands of the GC, and the scheduling too, this can also be a problem

it's actually not hard to solve these problems if you don't build out a whole system like this isn't going to be an issue ever as you squeeze to the edge of capabilities

doing the same level of scale in C++ and C are also both extremely challenging to achieve, but it's just not true you can't do it with Go

it just requires ... you know... fully writing your own memory management and scheduling code, you know, like the old days, like exactly the same how it has to be done from the start with Rust, C++, or java

making a decision to not use a language that gets you to MVP and doesn't take forever to retrain your programmers, and for which this kind of edge case of the last 10% of juice you are trying to squeeze out of your hardware, when for still less cost and time, you can get advanced systems programmers like me to ... you know... write algorithms... that fix the scheduling and memory management problem

but no, instead swallow the kool-aid from nutscrape incorporated and use their absurdly complex language with its ridiculous objects and traits and lifecycles and shit so you can look cool to your hipster friends

no, fuck you

i got better things to do than wait 5 minutes to compile a simple server on a 100x a day basis, thanks