Discussion: Plans for Julia as a general-purpose language?

Latency due to the need to constantly re-compile code is a huge issue (in my opinion this is by far the biggest problem with the language) that everyone is abundantly aware of and it is being worked on. There are many threads in this forum discussing it.

That’s really the crux of it. Once it is possible to easily cache and restrieve compiled code between distinct sessions of the Julia run-time, the above problem is solved.

This is related to the above, but would require “pruning” functions from the cache which would not get used. I’m not sure how easy this is to do. This may be a more difficult problem, I’m not sure how much thought has been given to it so far, it certainly comes up less often than the need for compile caching.

Python can do this because Python is just the interpreter, that’s it. All of Python is just the execution of a single program, the interpreter, it doesn’t need to store actual compiled code for anything the the Python stdlib or anything like that. Of course, this is a bit of a lie, because to do anything useful in Python, one typically needs compiled code to call upon (e.g. numpy, Cython components of pandas), but that compiled code lives with the individual packages, not Python itself. You can still typically get much smaller binaries that way than with Julia, simply because there’s often less compiled code and you can more easily select which binaries you want to bundle.

Perhaps you are simply not aware of how it is possible to load code? I suggest starting here and here. There are quite a few options for how to do this in Julia

  • If you want to bypass the package manager altogether, you can include the file containing a module declaration and do using .ModuleName (ok, that’s 2 commands).
  • You can add the package in the standard way with the package manager with ]add.
  • You can point the package manager to a particular directory with ]dev.
  • You can modify LOAD_PATH (I don’t recommend ever doing this).
6 Likes