Re:Data Science in Julia for Hackers
by newswasboring on Saturday March 20, 2021 @07:25AM
(#26522331)
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.
To me separating compiler and interpreter looks like a new two languages problem (maintaining consistency seems difficult)
Re:Data Science in Julia for Hackers
by jakobnissen on Saturday March 20, 2021 @06:38AM
(#26522082)
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.
2 language problem for the Julia developer. Also these two languages might drift apart over time
Re:Data Science in Julia for Hackers
by CyberDildonics on Saturday March 20, 2021 @09:20AM
(#26523023)
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.
It's not a problem if the language spec is well defined. Scheme distributions often do this.
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.