Hi!
I would like to distribute my julia program.
If I use https://github.com/dhoegh/BuildExecutable.jl or https://github.com/JuliaComputing/static-julia or https://github.com/JuliaLang/PackageCompiler.jl it clutters the build folder with dll files, most of them unnecessary, judging by name. Does it always compile the complete julia engine into the result? Is there no way so that only used functions are included? Am I doing something wrong?
Any help appreciated!
As I understand, being a very dynamic language, Julia is just-in-time-compiled. Hence, I’d expect the entire runtime environment to be included. It seems that some of these packages may be for pre-compiling modules to reduce startup time, not for making a complete static image since you can always trigger new compilation at runtime via automatic type specialization.
I understand. Then can you all just make Julia static for me please? 
That’s such a shame. I don’t really understand this… Julia was clearly devised with performance and technical computing in mind… I don’t see how the huge dynamic type system and “eval” add value to this I must say.
Is it likely that at some point one will be able to compile into lightning fast teeny tiny but statically typed executables that just includes the functions it uses?
The great advantage of Julia is that it produces it compiles “dynamic” code into binaries that look very much like statically compiled code. You will find that ultimately efficient Julia code runs with performance comparable to fully AOT compiled languages such as C++ (and better in some cases). It is extremely well suited to technical computing despite not being fully AOT. Having come from C++ myself I can understand you being somewhat skeptical about this, but I’m sure that if you give it a chance you will find not having static binaries not to be a significant disadvantage.
eval can be useful, but it is not something that most users use often, and is almost never necessary. The primary use of eval is usually in generating “boilerplate” code, but even in that case it is often better to use macros and generated functions. In fact, I would recommend that beginners not use eval at all until they have a bit of a better understanding of the Julia compiler.
Yes, everybody definitely wants this, it has been discussed extensively on these forums, but it just isn’t a priority yet. You will find that for the vast majority of applications it simply isn’t necessary. There has been some experimentation with this, see here. I strongly suggest, however, that you first explore “dynamic” Julia. It probably isn’t at all what you seem to be expecting. The disadvantages the Julia JIT compiler have compared to static code are really very minimal in the context of scientific computing.
That’s not necessarily true. Julia can in many circumstances be statically compiled. Although there have been blog posts showing how to do it, that route hasn’t been well explored with tooling. The development of the tooling for this just hasn’t been prioritized.
I am working for a company and I was hoping to significantly speed up my development time by switching from c++ to Julia. The thing is that the final project will be distributed to end users and I can’t expect they all have Julia installed.
I will still use it for experiments and rapid prototyping since I really love the syntax, it has so many neat solutions to things I was sighing about when using other languages. Nested multiline comments, nested for-loops from which I can escape all the way, Greek variables, a cross for cross product, a dot for dot product… so many little things are so awesome…
But I really need the binary thing for this to become my goto language.
Unless your end users run embedded systems, is 200MB really considered “large” these days?
Also, if you have a commercial application, consider contacting Julia Computing for a quote, they may be to come up with a solution specific for your requirements.
The program that my program becomes a plugin for is 6MB. I can’t do this, it’s just wrong.
That’s reasonable. The 200MB footprint that Julia currently has is quite large and we’d like to get it down, especially in the case where you’re compiling your Julia code to a standalone binary. That ability is not straightforward yet, however.
Is that something that can be done in retrospect? I would have thought that something like this has to be kept in mind during development from the beginning…
One of the developers has been working to make this happen, and has an old blog post showing how it can be done. It’s just the tooling to make it easy doesn’t exist, and tooling can always come later. There are some dynamic parts of Julia which are incompatible with running completely without a binary (like @generated functions and @eval) unless you statically compile some of their resulting codes, but in general most of Julia is statically compilable almost by design.
The relevant blog posts:
Hi there! Are there any updates on this, now that Julia has been evolving and I bet a godzillion people want this to work? 
I would not expect this to be a priority before v1.0 at all, no.
But will it be at some point? Do people still want this?
The thing is, I fell in love with the Julia syntax so much that I can’t go back to c++ now
So I am currently trying to include many of Julia’s concepts into c++:
https://github.com/mqnc/fiascode
I’d immediately stop with this if this issue was resolved.
It’s definitely something that many people want, but as @pkofod said, the people who would work on this are very actively working on Julia 1.0, especially getting compile times down, so don’t expect much progress until post 1.0.
Now that Julia 1.1 is out, will this issue receive attention again?
I concur with mircode on all points
I can imagine there is a significant amount of work involved to make this not only possible, but practical for lesser mortals. Providing feedback about “how on earth do I decide what code to produce” while leaving the door open for e.g. dynamic dispatching does not sound like a piece of cake to me!!!
Please see Compiler work priorities. This would fall under point 4 (PackageCompiler). So it’s on the radar but not top of the list currently.
@mircode is right. I was quite surprised by the size of the resulting “distributable” compiled binaries. Considering the output size, PackageCompiler.jl looks more like a proof of concept. Would be fantastic to compile Julia code in standalone dll’s of decent sizes. That would give a certain edge over R or Python (attempts are made there as well), is a pity the compiler priority is so low.