Die Kernidee bei Go basiert auf Hoare's CSP:
https://en.wikipedia.org/wiki/Communicating_sequential_processes
Das skaliert mit 4-6 Prozessen noch recht gut, aber leider muss jeder Prozess immer nachschauen, ob endlich eine Nachricht da ist, ohne die er nicht weiter machen kann: Die Synchronisation von Go Coroutinen enthält einen prinzipbedingten Anteil von Polling, was be mehr als 6 Kernen nicht nur den Overhead (O n²) explodieren lässt, sondern die Energieeffizienz mindert.
Die Kernidee bei Rust basiert darauf, dass der Compiler bereits den Code in Segmente teilt und die priorisiert auf eine Art priorisierten TODO Stack legt. Die CPUs greifen sich dann den Code mitsamt Erlaubnis, auf Variablen zugreifen zu können, und arbeiten den dann ab. Ist eine CPU frei, schaut die wieder auf der TODO Liste nach, guckt ob neue Arbeit da ist.
Das Konzept von Rust ist daher im Prinzip "verklemmungsfrei", die Auslastung der CPUs liegt eigentlich immer bei 100%.
Angesichts der neuen AMD CPUs mit 64 Kernen, 128 Threads ist Go also garnicht mehr gangbar.
Der Artikel ist - vermutlich unwissentlich und in guter Absicht geschrieben - eine fatale Irreführung des Lesers, möglicherweise sogar IT Entscheiders.