But sure, though I don’t really buy the argument that JIT compilers would “severely limit” the type of optimizations - there is no significant performance difference - if any - between AOT compiled managed languages and JIT-compiled ones. Sure, there are more constraints in case of a JIT, but it’s not like going in the other direction and letting gcc/clang chew 10x time more on the same program would give you a significant speedup, if any. Speculations (which are not possible AOT) may even reverse the fields.
D, Haskell, OCaml, Go are all in the same ballpark as Java and C#, and even JS, hell, they may be better.
Imagine a language as easy to use as Python, with the strong typing of Typescript, but designed from the ground up to always be fully compiled and hence running as fast as C++, but with build times measured in fractions of a second... fast enough to feel interpreted.
This extra optimization is somewhat offset by the very point of a managed language: the programmer don’t want memory layout details to leak into the design/APIs, but in the rare case it is needed it can be done just as well with the escape hatches they provide (byte buffers, value types also bring you quite far). But business logic seldom involve these scorching hot loops to begin with, so there may not even be anything to optimize in this manner.
I can only think of Ruby and Python that use a strictly interpreter mode (in their most common runtime).
Java, C# use a hybrid solution, but for all practical purposes they are running as extremely efficient machine code, how is it not “efficient business language”?