I’m loving Julia and I have built optimization algorithms with it that are blazingly fast (runtime and development!) and I don’t see any reason to port them into C/C++ or similar for speed-up reasons. What I would need in the future is the static compilation of Julia programs. I read somewhere that it is in the works at some capacity but I haven’t seen any estimates when it would be ready for use somewhat easily without much of a hassle?
Yeah, I really would like to hear an update as well. I think one major power of Julia may be it “replacing C” as a productive language to produce efficient binaries which other languages may use (think of people in R/Python using standard bindings to Julia libraries).
Another (potential) Julia user here interested for the same feature…Moreover, I still believe there is place for non-browser-JS-based desktop apps and statically compiled executable would fit it nicely.
I have been testing out the capabilities described in the blog post and most of it them broke since the post. I have been filing issues to get them fixed, but its slow going. You can see the progression here:
(I’m definitely following this (from a distance) and would like to make binaries for DiffEq and make R, Python, and MATLAB packages which use this once it’s more developed.)
I am already a convinced user, but what is lacking for me to completely switch to Julia (and convince the company I am working for) is a clear roadmap when static compilation will be continuously available as a built-in feature. I would be glad to hear about any progress in this direction.
I have made little progress on the issues linked above. The developers have made it pretty clear that this feature is a low priority, so I wouldn’t expect to see progress in the near future.
Julia is a dynamic language, so completely static compilation is unlikely to ever be possible in general (i.e. for completely arbitrary Julia programs). Some runtime compilation will often be needed.
However, if you just want to call Julia code as a library, e.g. from C, that is already possible as long as you are willing to link to libjulia.
I’m a little confused that in order to switch from Matlab and Python – both dynamic languages without static compilation – it’s a requirement to have static compilation. What exactly is the requirement? Is it about type checking, code generation, or bundling of dependencies? These are all pretty independent issues but often conflated under the umbrella of “static compilation”.
I think he’s conflating the idea that you can build executables for MATLAB/Python/R scripts. This is different than static compilation, and akin to bundling libjulia with the script in an executable. I think this is a much easier target, and likely a first goal for a lot of people (at least, a way to do it easily).
After reading a few posts on the subject I think people want static compilation for 3 reasons:
1- many julia codes don’t need to be dynamically compiled, a real complete static compilation with optimizations would completely remove the JIT compilation overhead.
2- deploying code and making code distribution easier generating both libs and executables - there are come ways to acomplish these with userimg or buildexecutable. We still get very big programs but I think people have been working in shrinking base which should make it better.
3- some people see generaring libs and execs as methods of hiding proprietary code, I don´t think this is the way… maybe obfuscation is a way to go…
Also, 2 does not solve 1 right? I think it still does not eliminate the need of JIT compilation right before running the code.
Read @joaquimg’s summary above. What you’re asking for isn’t static compilation: it’s compilation of a script to an executable that includes the Julia runtime. This is what MATLAB/Python/R do, which is why the resulting executables are large.
Julia can actually do something else as well: it can generate all of its compiled code and make that executable without Julia. This second case is static compilation, and is more akin to compiling C than it is to compiling MATLAB/Python/R. But it has more restrictions: it cannot do anything that requires the Julia runtime (no @eval and no @generated).
Either way it generates binaries that hide code. But they are different.
What you are responding to is not written by @MatthiasErdmann - it looks like he tried to quote @StefanKarpinski but something went wrong with the discourse formatting (just trying to clear out confusion - this thread is interesting reading).
Firstly, because I am not even close to a specialist in the matter, so I will tell you what I know, that might be imprecise or sometimes wrong.
Given a executable one can extract assembly code, and even convert to C… It will result in a messy code.
Many of the ways people use to put python and R code into execs do not generate assembly code they simply hide the script, so its usually possible to extract the script completely (including comments!). Thus the right thing to do in this case e just code obfuscation and that has nothing to do with static compilation, its just some kind of indirect consequence for languages like C.
I am not sure about the julia process, someone else might it explain and even correct me in whatever mistake I might have made above.
But the 3 topics I presented are independent and people do mix them when talking about static compilation:
remove JIT overhead
make a program more compact easier to distribute
obfuscating the code
In particular, I am more interested in 1 and a little bit in 2 (that can be partially solved by BuildExecutable.jl and the userimg.jl method). 3 might me solved by some routines of replacing words, spacing, tabs, comments etc.