Here we go again. Those allocations and run time can be avoided entirely using sysimages. Latest vscode extension gives a convenient build task for this.
It seems like every time julia is mentioned, someone has to clarify this.
The problem I seem with sysimages, is that the whole process is incredibly unergonomic for exploratory coding, which Julia always claims it is a primary use-case for. When you want to just glue some packages and quickly test out some results, the last thing you want to do is to think about what kinds of functions from libraries you are going to use beforehand, carefully write it in a precompilation file, and wait for the compiler to precompile and cache those code paths! And once those dependencies change even a bit you need to wait for precompilation again, which happens a lot when you're prototyping things fast or upgrading versions (for example, this X numerical computation library doesn't have a particular feature I want to use, so I want to switch to another library Y, but then you need to wait for everything to be precompiled again) The reality is that most people just want to fire up a virtualenv and do the occasional "pip install <my libraries>" and don't want to get involved in any of this stuff. (As someone who uses C++ I have a lot more patience than other people, but you shouldn't really expect much from others)
I think Julia needs to throw away some of the unnecessary obsession for just-ahead-of-time (JAOT) compilation. Compiling everything beforehand to LLVM machine code seems good for raw runtime speed, but it doesn't matter when it takes so much setup time to even just glue some simple libraries. Julia should seriously consider running most of the less-computationally intensive codepaths in a custom-made interpreter without LLVM, while precompiling the numerically intensive parts of library code in raw machine code with the current LLVM backend. Maybe there should be a flag you can use to mark certain functions to be unconditionally compiled AOT-style, and leave the rest to the interpreter. Interpreters can be made surprisingly fast with some effort - stuff like the interpreter in LuaJIT (https://luajit.org/) and HashLink (https://hashlink.haxe.org/) is what comes into my mind.
Regarding your first paragraph, I must ask, have you done significant coding in Julia? Because an outdated sysimage is not really that big of a problem in practice. I have a sysimage which includes common big packages for plotting, numerical computing and some prettifying stuff I like like OhMyREPL. Then during dev time I add and remove packages, the compile time for those is significant enough to be noticed but not significant enough to be a problem. Because of the great composability of Julia, I'm guessing internally its using those big libraries and thus find most stuff precompiled for them. But I can't be sure about that.
Anyways, this is just my experience and my job involves a lot of waiting and stuff anyways so a couple seconds here and there doesn't bother me.
It would be the same code running on two different backends, so there would not be a two-language problem. Just like how GCC and Clang don't give C a two-language problem.
They just explained to you that this idea has nothing to do with two different languages and that there are other examples of having multiple compilers for one language.
If it worked by default out of the box, nobody would have to "clarify" that you can decrease Julia's computational slowness by increasing the human time and effort spent on cache management
It seems like every time julia is mentioned, someone has to clarify this.