5 ms·

Is it possible yet to compile ahead-of-time to a stand-alone binary executable?

newen 7y ago
Look under Static Julia Compiler here [1]. I've successfully done it in Linux, don't know about Windows. It doesn't work when you have binary dependencies like GTK, etc. [1] https://github.com/JuliaLang/PackageCompiler.jl https://github.com/JuliaLang/PackageCompiler.jl
cultus 7y ago
Yes, with PackageCompiler.jl. There are some restrictions IIRC since it is a dynamically typed language. https://github.com/JuliaLang/PackageCompiler.jl https://github.com/JuliaLang/PackageCompiler.jl
deleted 7y ago
[deleted]
cmcaine 7y ago
The other replies are slightly out of date and imprecise. PackageCompilerX replaced PackageCompiler (and there's a PR open that will pull all the X work in soon). The binaries produced bundle the whole Julia sysimage by default and they're quite big, but they are quite fast! A more traditional static compilation approach is being tried with StaticCompiler.jl by tshort, but it's in early development.
- cosmojg 7y ago
  > A more traditional static compilation approach is being tried with StaticCompiler.jl by tshort, but it's in early development. The moment this ships, there will no longer be any reason to use any other garbage-collected language.
  - eigenspace 7y ago
    What does this have to do with garbage collection? If your concern is about latency in real time systems, Garbage collection isn't the problem, heap allocating memory is. Julia makes it easy to never allocate anything on the heap (unlike most garbage collected langauges). Check out this talk this discusses this in detail in the context of robotics: https://www.youtube.com/watch?v=dmWQtI3DFFo https://www.youtube.com/watch?v=dmWQtI3DFFo
    - snicker7 7y ago
      I think the above poster is referring to languages like Go/Java/C#/Nim/whatever. Like Julia, these languages have a significant runtime. Unlike Julia, their apps can be compiled AOT into standalone executables.
      - cosmojg 7y ago
        My point exactly! Thanks for clarifying.
        eigenspace 7y ago
        Right, but you said > there will no longer be any reason to use any other garbage-collected language. (emphasis mine). I was just curious as to why you specified garbage collected there.
        cosmojg 7y ago
        I equate garbage collection with larger static binaries. Julia's static binaries are especially large since they package the entire sysimage. I'm excited about StaticCompiler.jl because, by cutting out the sysimage, it promises to make Julia more competitive with other garbage-collected languages like Nim, Go, Crystal, etc., all of which produce relatively small static binaries. However, like these other garbage-collected languages, Julia is unlikely to ever compete with the likes of Zig, Rust, C++, etc. which produce even smaller static binaries since they don't have to ship a GC runtime. That's why I specified garbage-collected languages as, in my opinion, the addition of proper static compilation will allow Julia to completely supersede other garbage-collected general programming languages but not manually managed systems programming languages.

Look under Static Julia Compiler here [1]. I've successfully done it in Linux, don't know about Windows. It doesn't work when you have binary dependencies like GTK, etc. [1] https://github.com/JuliaLang/PackageCompiler.jl https://github.com/JuliaLang/PackageCompiler.jl

cultus 7y ago

Yes, with PackageCompiler.jl. There are some restrictions IIRC since it is a dynamically typed language. https://github.com/JuliaLang/PackageCompiler.jl https://github.com/JuliaLang/PackageCompiler.jl

deleted 7y ago

[deleted]

cmcaine 7y ago

The other replies are slightly out of date and imprecise. PackageCompilerX replaced PackageCompiler (and there's a PR open that will pull all the X work in soon). The binaries produced bundle the whole Julia sysimage by default and they're quite big, but they are quite fast! A more traditional static compilation approach is being tried with StaticCompiler.jl by tshort, but it's in early development.

cosmojg 7y ago
> A more traditional static compilation approach is being tried with StaticCompiler.jl by tshort, but it's in early development. The moment this ships, there will no longer be any reason to use any other garbage-collected language.
- eigenspace 7y ago
  What does this have to do with garbage collection? If your concern is about latency in real time systems, Garbage collection isn't the problem, heap allocating memory is. Julia makes it easy to never allocate anything on the heap (unlike most garbage collected langauges). Check out this talk this discusses this in detail in the context of robotics: https://www.youtube.com/watch?v=dmWQtI3DFFo https://www.youtube.com/watch?v=dmWQtI3DFFo
  - snicker7 7y ago
    I think the above poster is referring to languages like Go/Java/C#/Nim/whatever. Like Julia, these languages have a significant runtime. Unlike Julia, their apps can be compiled AOT into standalone executables.
    - cosmojg 7y ago
      My point exactly! Thanks for clarifying.
      - eigenspace 7y ago
        Right, but you said > there will no longer be any reason to use any other garbage-collected language. (emphasis mine). I was just curious as to why you specified garbage collected there.
        cosmojg 7y ago
        I equate garbage collection with larger static binaries. Julia's static binaries are especially large since they package the entire sysimage. I'm excited about StaticCompiler.jl because, by cutting out the sysimage, it promises to make Julia more competitive with other garbage-collected languages like Nim, Go, Crystal, etc., all of which produce relatively small static binaries. However, like these other garbage-collected languages, Julia is unlikely to ever compete with the likes of Zig, Rust, C++, etc. which produce even smaller static binaries since they don't have to ship a GC runtime. That's why I specified garbage-collected languages as, in my opinion, the addition of proper static compilation will allow Julia to completely supersede other garbage-collected general programming languages but not manually managed systems programming languages.