> Julia's "secret sauce", the dynamic type system and method dispatch that endows it with its powers of composability, will never be a feature of languages such as Fortran. The tradeoff is a more complex compilation process and the necessity to have part of the Julia runtime available during execution.

> The main limitation is the prohibition of dynamic dispatch. This is a key feature of Julia, where methods can be selected at run time based on the types of function arguments encountered. The consequence is that most public packages don't work, as they may contain at least some instances of dynamic dispatch in contexts that are not performance-critical. Some of these packages can and will be rewritten so that they can be used in standalone binaries, but, in others, the dynamic dispatch is a necessary or desirable feature, so they will never be suitable for static compilation.

The problem (which the author didn't focus on, but which I believe to be the case) that Julia willingly hoisted on itself in the pursuit of maximum performance is _invoking the compiler at runtime_ to specialize methods when type information is finally known.

Method dispatch can be done statically. For instance, what if I don't know what method to call via abstract interpretation? Well, use a bunch of branches. Okay, you say, but that's garbage for performance ... well, raise a compiler error or warning like JET.jl so someone knows that it is garbage for performance.

Now, my read on this work is the noble goal of prying a different, more static version of Julia free from this compiler design decision.

But I think at the heart of this is an infrastructural problem ... does one really need to invoke the compiler at runtime? What space of programs is that serving that cannot be served statically, or with a bit of upfront user refactoring?

Open to be shown wrong, but I believe this is the key compiler issue.