The reason why C or Rust are fast is primarily the increase data locality. In java, js or python everything is a pointer. Fetching random parts of memory is expensive therefore if you want to keep the CPU fed with data you need continguous data structures. In theory nothing other than data locality stops JS from being faster than C and the proof is webassemby which gets 50% of the performance of native code which is really impressive considering that webassembly runs inside a sandbox that prevents glaring security issues like bufferoverflows on the stack from rewriting the return address.

> What makes Rust, like C or C++, 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.

Consider that javac and the Java runtime have received plenty of resources and development time (since 1995 or so!).

The overhyped claim in the early days of Java was that it would be "faster than C" due to JIT optimizations. That has certainly turned out to not be the case. Further, Java and all the other managed languages (to include the CLR languages) remain unsuitable for real time applications due to GC pauses.

As this article points out, memory consumption for JVM based systems is also usually vastly higher than for C/C++/Rust/Ada.

C++ in particular has been a dumpster fire of a language, and IMO has set the industry back considerably. It's good to see Rust and a few other languages providing much better alternatives in the same space - languages suitable for lean, real time, high performance applications.

> What makes Rust, like C or C++, 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.

Actually lots of money spend across compiler vendors in the last 30 years, and UB abuse, as C compilers were pretty lame in the early 80's.

There was no need to "well actually" that, as it is the same point the parent was making: that money (and UB abuse) is why the tuned compilers now exist.

I interpreted differently, as if being an inherent property of how C and C++ were designed.

> UB abuse

That baseless assertion makes no sense. UB is a property of the ISO standard and has no effect on how compiler vendors implement the language. In fact, UB is intended to enable vendors to be free to choose how they implement that behavior. So why do you believe that the freedom to pick how you implement something hinders any development effort?

I don't know, maybe the daily CVE reports including some Linux exploits, in spite of the kernel review process and static analyzers?

I agree that the Go compiler doesn't optimize as aggressively, but it's not that simple. I've heard of a rewrite of some legacy code from C++ to Go making the code go faster.

A rewrite often includes a redesign, which can make more of a difference than compiler optimizations.

If they ported back to C++ again, it would probably be faster still. But there are also maintenance concerns to think about.