I wonder what kind of performance setback this resulted in.
Didn't JavaScript runtimes get close to C/C++ performance exactly because they started using JIT compilation?
Didn't JavaScript runtimes get close to C/C++ performance exactly because they started using JIT compilation?
You can AOT compile them, but the code cannot ever be optiomal without any kind of PGO feedback loop, thus a JIT ends up being a much better option.
Unless they support optional types, like in the Lisp based languages.
So something like Typescript could eventually have a good AOT story, and this is what Microsoft does on their MakeCode project, compiling a Typescript subset via C++ code generation.
I guess another reasonable strategy would be to instrumentalize the code, run it once, and feed the results back to another AOT compiler pass which then optimizes the code based on usage statistics. But that would not apply to Go really, because it has strong typing already.
Languages that benefit from JIT compilation are languages with a dynamic type system: the JIT profiles the hot paths to optimize (e.g. this function is called a lot with integer parameters but only once with string parameters, so I'm going to compile the version with ints to optimal code and compile the string version to a suboptimal but inexpensive code)
Go on the other hand has a static type system, so when you AOT compile it can already produce all the optimal code needed thanks to static types.
Type information is not the only thing that helps though. Partial specialization can be applied to other things.