These systems usually spend a lot of time waiting for network/disk IO, which means there is plenty of CPU time available to do the computations or GC runs, and

These systems usually spend a lot of time waiting for network/disk IO, which means there is plenty of CPU time available to do the computations or GC runs, and the added memory pressure isn't so significant. The Go runtime is also finely tuned for exactly these kinds of workloads, with language level insight into blocking operations. If we take the Tokio async runtime for Rust: it's not exactly the fastest runtime out there, comparatively new, you need to carefully avoid introducing blocking calls that stall the worker threads, there is no language level integration, and Rusts trait system currently often requires boxing of futures. Combine all of that and you often end up with code that isn't noticeably faster than Go in practice. One counterpoint though: I've found that Rust code takes longer to write, but it's significantly easier to refactor, thanks to the much stronger type system.