Part of what I see m0th87 saying, though, is that practice has shown that these claims about JIT compilation handling certain cases more effectively than AOT co

Part of what I see m0th87 saying, though, is that practice has shown that these claims about JIT compilation handling certain cases more effectively than AOT compilation just don't really hold true. JIT compilation may be better than some of the other approaches for implementing VMs or interpreters. It may also theoretically have the potential to be better than AOT compilation in some cases, too. But that potential doesn't really matter if we never see such benefits in real systems. Real-world code written in C, C++, and Fortran and compiled ahead of time still basically always outperform Java bytecode executed by HotSpot, or JavaScript code executed by V8, or Lua code executed by LuaJIT, by a huge margin. This is even after a huge amount of effort has gone into systems like HotSpot and V8, for instance. The theoretical benefits of JIT compilation do us no good if it's too costly or difficult to build effective implementations of such systems in a timely manner, for example. It does the wider community no good if such optimizations only really apply in a very small number of highly specific cases, as well. A lot of us have heard these claims about JIT compilation for over a decade now, especially with respect to HotSpot, but we've yet to see these techniques consistently and reliably match AOT compilation in general, never mind outperform it. There is a lot of doubt out there due to this.