Statically compiled and statically linked


I love the syntax of julia, but, unless julia became statically compiled & statically linked and enables cross compilation, i will use julia as my one and only language. For the mean time there’s and Good luck for


So you are using Julia now? That’s great. And don’t worry, static compilation is not on the immediate horizon, so you can keep using Julia as your one and only language.


Yes!! As I’ve said, I love the syntax, but i love most the statically compiled and statically linked programming languages like Being able to compile a statically linked executable for any specific platform from one platform is the greatest, for me. If can do that, I would be very happy for using julia.



I’m pretty sure the OP was asking for static linking/compilation, not a deliberate avoidance of it. In any case, the absence of (static) compilation is also one of the things holding me back from using Julia more at work, so I’m really hoping you’re wrong :slight_smile:


With respect, if static compilation/linking is the key feature for someone, why would they want to use an essentially dynamic language?

Standalone binaries are one thing, but they would still need to include the compiler (or just interpret things which were not compiled). There are great statically compiled languages out there… but of course they lack the convenience of Julia. But that’s not a coincidence.


I think the focus on “statically compiled” etc is just because that’s the format that usually offers what we want.

The real demand is much more in line with a dynamic language like Julia.

Most users would be totally happy if they can ship a single julia “binary” to their customer/department/non julia programmer - which they can just execute and which doesn’t take a full 5 minutes to compile everytime you start it up.
Because that is indeed a deal breaker for most people!

Especially if someone doesn’t already have julia installed, installation times with download, precompilation, etc easily range between 10-60 minutes right now.

There is no question that this needs to be addressed, especially if we want to reach a wider audience :wink:


I have not been following this topic very closely recently, but I though you had a package that tackles this problem?


Yeah, we’re on it :wink: Pretty sure this will be solved over the next year!
Right now there are quite a lot of show stoppers when using PackageCompiler, so lot’s of work still needs to be done.
Sadly, I’m not super well informed about Julia’s compilation or even compilation/linking in general, so my personal progress in PackageCompiler has been a bit slow - especially since I also want to push out a release of a new GPUArrays / CLArrays and Makie soon :stuck_out_tongue:


(Hey @sdanish, glad to hear about Makie! Looking forward to that!!)


So true…


No doubt go is a viable option. I use it a ton for projects, but these also tend to be more typical business software projects. But doing data science, machine learning, et al., not so easy due to lack of community. Crystal, Pony, Nim, D… have even smaller communities and they lack that “killer” app to drive adoption. Rust is interesting but it’s hard to tell where the community is really heading, whether adoption is real (versus flash-in-the-pan interest from people that end up bailing on the language), and whether people continue to build production code with Rust due to lack of packages plus long development times (think haskell, people love it but it rarely makes it to production). Swift remains to be seen in terms of “server side” adoption and use. In the case of many of the previous languages, c++ will be the likely fallback.

Also, it’s not clear for areas like data science that a compiled language is a benefit overall. ad-hoc data analysis and exploration come to mind. the start up of a jit, or having to wait for things to re-compile are still faster than writing compile scripts with strict type enforcing (i wrote one-off data scripts in go for years doing lots of data engineering tasks. and while it was very easy and fast in go it likely would have been faster to write the code in ruby or python).