I know about PackageCompiler.
Thank you for that package, without it , I would have not considered using Julia.
I was wondering if there is a plan to have small exectable file that can easily be distributed for future Julia or PackageCompiler releases?
A lot of other programming languages (C/C++, Rust, Go, …etc) allow the creation of relatively small single exe file where Julia creates a lot of dll/exe files.
From my point of view (at least) that is one of the major feature missing from Julia.
Thank you for the link.
Indeed it looks like a really long way to go.
I believe it would have been good to integrate that feature at the very beginning when designing the language. It is a very common and useful thing.
Guess we will have to be very patient…
Thanks.
I disagree, and I think many people here do too. If we wanted to do small excecutables first, features and ease of use later, we would be inventing FORTRAN.
To me standalone would be nice, but it’s by no means a killer. Most people in my vicinity use MATLAB or Python, neither of which does standalone all that well, and the decisions that I like best about Julia are the ones that currently stop it from getting entirely ahead-of-time compiled. If the developers had chosen to focus on that instead, I would have had 0 reason to even look at Julia.
You are completely misinterpreting what I wrote. I never said it is a “killer”. I just said it is major missing feature (from my point of view only) and that it would have been good to integrate it from the beginning. You are making a lot of extrapolation…
Let’s get some context here. The reason why statically compiling Julia code is hard is because Julia is a dynamic language; specifically, anywhere you have dynamic dispatch points in your code (intentionally or by accident), the compiler typically cannot know what methods (and thus what code) will be called on the other side of the dynamic dispatch. So, unlike static languages like C or Fortran, it’s not guaranteed that a given valid Julia function can actually be fully statically compiled to machine code.
Of course, thanks to the power of Julia’s compilation tracing mechanisms, you can ask Julia’s compiler to tell you what methods were executed when running a piece of code that you care about, and you can use that information to compile the methods that you know you’ll need, although you’ll still need Julia’s runtime library available to ensure that dynamic dispatch still works.
So why have dynamic dispatch at all? Dynamic dispatch is a core part of how the language works, and makes many code patterns possible. Without it, you couldn’t just print(obj) on your custom struct; you’d instead have to define some print_my_obj function every time, which is cumbersome. You’d also lose many kinds of composable patterns that are key to certain parts of the ecosystem.
The bottom line is that dynamic dispatch is here to stay, and so we need to work around it to make static compilation work. The work around isn’t easy, so static compilation is still work-in-progress until we figure out how to support it well.
To elaborate on this, when you make a new language, you pick a few principles and work from them. They are not all compatible. Some languages pick having strict rules for checking types and generating small binaries. Julia picked, among others, having an excellent interactive experience, which pretty much implies dynamic language, which in turn is at odds with easily generating small binaries. You’re basically telling us we should have picked a completely different set of principles to design a language from. Which is a fine opinion to have—and there are many languages that have chosen different principles. But it’s not like we just forgot or weren’t aware of compiling programs to small binaries.
I wonder if this forum would benefit from a tag/triage system for bikeshed topics such as these, to include static binaries, 2 .^ (-1:3), invalid redefinition of constant MyStruct, etc.
Are you sure? I cannot find any support for that from an (admittedly brief) google search. Most seem to claim that ‘bleeding edge’ is a pun on ‘leading edge’.
In order to work on this, I wonder if macros can be used to enforce a “semi-dynamic” dispatch, sort of like C++. It’s dispatched at runtime, but you cannot change vtable at runtime.
Is this really the case? Why not remove dispatch when generating the machine code. Besides, the fact that it works means that the machine code has already been generated.
I don’t know if you’re familiar with the process of generating onnx files, but it is a model generated by tracing the execution process.
I believe that one has already established what type of input the program will have when it is being compiled into machine code.
Assuming you never use eval and friends, it is possible to convert all dynamic dispatch points to a fixed table lookup based on argument types (essentially hard-coding dispatch rules into the generated code).
What you’d lose by doing this is the possibility to compose multiple such libraries of generated Julia code together, because some libraries might use types that weren’t accounted for when generating the fixed table for a given library. That might be irrelevant for some use cases, so having this fixed table generation be optional seems most appropriate.