I love Julia’s efficiency and the speed with which I can complete certain tasks once it is compiled. The only slight gripe I have as a data scientist, especially when exploring large datasets, is the time needed in the beginning for compilation, e.g. the time to first plot etc. I was wondering why a programming language such as Julia is not more of a hybrid between an interpreted and a compiled language. I.e. the time to first plot etc could be reduced significantly by implementing an interpreted solution, and in the background compiling begins, once compiling is complete it switches to that for the huge performance bump after. I’m sure this has been thought about before, I guess I’m just curious as to why it might not work?
Jeff Bezanson briefly mentioned this option in his talk about state of Julia on Juliacon 2021.
I guess it can be done, but there is a lack of people with the knowledge and time to do that.
The Julia v1.8.0-beta1 is a big step for a better user experience:
see : julia/NEWS.md at v1.8.0-beta1 · JuliaLang/julia · GitHub
Bootstrapping time has been improved by about 25%
The LLVM-based compiler has been separated from the run-time library into a new library, libjulia-codegen. It is loaded by default, so normal usage should see no changes. In deployments that do not need the compiler (e.g. system images where all needed code is precompiled), this library (and its LLVM dependency) can simply be excluded (#41936). Conditional type constraints can now be forwarded interprocedurally (i.e. propagated from caller to callee) ...
the basic answer here is that it’s totally doable, but requires a bunch of time from someone who knows a lot about Julia internals and compiler design, and most people who know about both of these things don’t have a lot of free time to work on this.
This is already implemented using the
Base.Experimental.@compiler_options macro. It should be mentioned though that GitHub - JuliaDebug/JuliaInterpreter.jl: Interpreter for Julia code can be quite a bit faster than Julia’s own interpreter, so depending on your use case you might even want to use that instead.