> n practice, Go can typically outperform Rust in throughput (using more memory), despite having a mountain of disadvantages against it in theory

This is a huge claim that disagrees with both my real-world experience and everything I've seen from artificial comparisons.

Every high performance Go system I've worked on has quickly reached the point where we're optimizing memory management and doing things that would have been explicit in a non-GC language like Rust anyway.

The Go runtime is amazingly optimized, but it comes with overhead over doing the same work directly in a lower level language.

This is the first I've heard anyone claim higher throughput for Go than Rust. Any articles you'd point to to learn more?

I think this is interesting and warrants explanation. There are cases where a GC can be faster (sort of, Arenas get you most of the gains) but "the most sophisticated scheduling engine in the world" should be easy to at least partially support.

> It's literally the most sophisticated scheduling engine in the world.

That seems unlikely regardless of how good it is. This is a domain where state-of-the-art research is not in the public literature. Scheduling is an AI-complete problem.

What benchmarks are you referring to?

Rust itself doesn't have a scheduler of course, I assume this is comparing against tokio or one of the other async executors?

What a joke, ignoring Erlang, and the custom schedulers from JVM and CLR runtimes.