For another perspective, look at Go versus Python: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
What makes C, C++ or Rust efficient is not just that they are statically compiled, it's that they have massively-tuned optimizing compiler spending a lot of time in compile-time optimizations. Go's compiler is way less aggressive with optimization because they wants to keep the compile-time low (which is probably a good idea in their niche) and because it has been much less of a focus than for LLVM or Gcc.
Also, the lack of generics and the pervasive use of dynamic dispatch (with interfaces) also prevent many optimization but it keeps compilation fast, which is what Go developers want. (Please note that this is not an argument in favor of Go developers not adding generics to the language, they could totally add generics but keep the dynamic dispatch to keep the compile-time as it is right now).
C code in the 80's was about 80% inline Assembly on 16 bit machines, so surely there is plenty of room to improve Go's optimizer if they so wish.
Of course Go will never fit into those PIC micro-controllers with 16 KB of RAM.
[0] https://internals.rust-lang.org/t/announcing-the-network-ser...
I'm not holding my breath for Rust dethroning non-perf-critical Go projects anytime soon.
I'm also use Go primarily to write any application that may needs parallel (Not just network service).
For me, Rust is a exciting new language that I could love to use if they can finally put all the async/await things together.
This should be removed, and I would say that it gave up on its design goal of being a systems language.
It's absolutely intended to be a [Google-style] systems language [in which one might implement a large distributed data system].