Although interpretation and Just-in-Time compilation were not new ideas at the time, Java first brought them to a wide audience around 20 years ago with its use of the JVM.
Anyone who remembers those times, and even many years beyond then, will remember how slow JVM-based applications were compared to native apps.
Even today, there's still a noticeable difference between JVM-based software and native software, although the exceptionally massive increase in computation power have rendered the differences easier to overlook in many cases.
Since then we've seen similar techniques used by a variety of other platforms.
Despite many years of effort and research, and much investment, we've yet to see Just-in-Time compilation rival Ahead-of-Time compilation in terms of the performance.
While Just-in-Time's supporters will claim that it allows for better optimization or better portability, or they can show some contrived benchmarks where it has a slight edge, we haven't seen such techniques stand up in the real world.
Ahead-of-Time C and C++ compilers have consistently compiled software that's very fast, lean, and the best performer in real-world scenarios.
For years, we've had people pointing out this very obvious reality regarding how Ahead-of-Time compilation proves to be superior to Just-in-Time compilation in realistic scenarios. Yet we've seen their claims very forcefully denied by the Just-in-Time advocates.
Maybe after 20 years, it has finally become clear that the Just-in-Time supporters were wrong, and that Ahead-of-Time compilation is the better approach.
With battery-powered devices more prevalent than ever, the need for high-performing and efficient binaries is greater than it has ever been. Returning to Ahead-of-Time compilation is just what we need given these circumstances. It's just a real shame it has taken so long for this important reality to be recognized.