This problem has been solved already by Lisp, Scheme, Java, .NET, Eiffel, among others, with their pick and choose mix of JIT and AOT compiler toolchains and runtimes.
No, those languages have not solved it. None of the languages you list there are actually as fast as C for tight inner loops, they sometimes get close under certain circumstances, but they're still very much 2nd class languages in terms of performance.
They're only "fast" compared to slow interpreted languages like Python.
Yes they have, because those microbenchmarks are tailor made for the winner, using a very specific compiler implementation with language extensions, which apparently is only valid if the language happens to be "C".
This is such bizarre cope. It's okay for a language to not have first-class numerical performance characteristics. Langauges can have other reasons to exist. Just don't like about the performance, that doesn't help anyone.
It is not coping, it is a two measures, two weights attitude when putting C into a pedestral, you even missed on C++, which all major modern C compilers are written on, and share the backend with some of those languages.
