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

**URL:** https://discourse.julialang.org/t/discussion-plans-for-julia-as-a-general-purpose-language/30861
**Category:** General Usage
**Tags:** question, performance, design
**Created:** [November 8, 2019, 3:16pm UTC](https://discourse.julialang.org/t/discussion-plans-for-julia-as-a-general-purpose-language/30861 "2019-11-08T15:16:28Z")
**Posts on this page:** 1
**Showing post:** 2

<div class="post-metadata">

### Author: ![ExpandingMan](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/expandingman/32/866_2.png) [@ExpandingMan](https://discourse.julialang.org/u/ExpandingMan)
#### Post date: [November 8, 2019, 3:35pm UTC](https://discourse.julialang.org/t/discussion-plans-for-julia-as-a-general-purpose-language/30861/2 "2019-11-08T15:35:24Z")

</div>

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.

> [@erezsh](#):
>
> is caching the compiled functions

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.

> [@erezsh](#):
>
> Executable size

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.

> [@erezsh](#):
>
> Python does the same trick of including itself, but needs only 30 megs. Perhaps there’s a simple solution to drastically reduce the build size?

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.

> [@erezsh](#):
>
> 1. Imports
> 
> Julia’s import system is probably its weakest point, in terms of user-facing design. Having to literally include files, and then import them separately, is awkward and inefficient…
> 
> Every modern language (and even most non-modern ones) lets you include your module using a single command, and makes sure to remove duplication for you.
> 
> The funny thing is that you can import a local module, if you just add the local directory to Julia’s path (which creates its own stack of problems). But perhaps it means that it would be very easy to implement?

Perhaps you are simply not aware of how it is possible to load code? I suggest starting [here](https://docs.julialang.org/en/v1/manual/modules/) and [here](https://julialang.github.io/Pkg.jl/v1/). 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).

---

_[View the full topic](https://discourse.julialang.org/t/discussion-plans-for-julia-as-a-general-purpose-language/30861)._