Lets not get carryied away with Go advocacy,

https://www.techempower.com/benchmarks/#section=data-r19&hw=...

I can't speak about go vs nim generally, but:

Our particular design is a bunch of single-threaded apps on a message bus. Each app (network ingress/egress, data handling, relays, etc) sits on the bus, and can use async/await to do IO concurrency, but on the app level, there's no threading and no locking to observe.

Each app also has a erlang-inspired supervisor task system, where each task is just a async proc kept alive. It's proven to be very robust (from the standpoint of service availability) in the face of bugs or input validation mishaps.

Nim also has an emit pragma where you can just inline C code (or code for the Javascript backend or C++ backend, etc.). So, if there is some poorly optimized (for whatever reason) hot inner loop you can fix it right there, though you start sacrificing portability (often the trade off for optimal performance). You can even do SIMD intrinsics right in Nim no problemo just using the FFI Nim has for C calls.

Python is written in C, and yet ...

Compiling to C really isn't relevant. "50 years of work on C compilers" is not at all relevant--languages that compile to LLVM get all the advantages of the optimization work.