In theory, a good JIT should, over a sufficiently long run time, outperform a native AOT-compiled binary, as it has more information about the code, processed data, and actual hardware. Similarly, a mix of manual memory management with GC should be potentially faster than a purely manual approach, due to a more efficient heap structure and allocator.
However, most state-of-the-art JITs & runtimes today are instead used to make somewhat performance-hostile high-level languages run acceptably (e.g., JVM, CLR, V8,...), rather than attempting to compete with AOT compilers for lower-level languages (C++/Rust/Zig/...).
This leads me to wonder, where are all the low-level runtime-based languages? Were there any serious attempts at developing a lower-level, runtime-ta...
In theory, a good JIT should, over a sufficiently long run time, outperform a native AOT-compiled binary, as it has more information about the code, processed data, and actual hardware. Similarly, a mix of manual memory management with GC should be potentially faster than a purely manual approach, due to a more efficient heap structure and allocator.
However, most state-of-the-art JITs & runtimes today are instead used to make somewhat performance-hostile high-level languages run acceptably (e.g., JVM, CLR, V8,...), rather than attempting to compete with AOT compilers for lower-level languages (C++/Rust/Zig/...).
This leads me to wonder, where are all the low-level runtime-based languages? Were there any serious attempts at developing a lower-level, runtime-targeted language with the explicit goal of beating exiting native languages on throughput? If not, why?
My current hypothesis is that for a sufficiently hand-optimized code in a low-level language, there are just not that many optimizations a JIT can do compared to a modern AOT compiler to make it worth it, but as someone mostly unfamiliar with JIT and runtime internals (and pretty familiar with AOT compiler internals), I'm looking for more qualified opinions. :)