HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
JuliaLang
PackageCompiler.jl
Julia2018–2023
JuliaLang / PackageCompiler.jl

PackageCompiler.jl

Compile your Julia Package

Explore on GitHubRead Hacker News discussions
30Distinct people
39Mentions
0Explicit recommenders
1.6KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Compile your Julia Package

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year39 dated mentions

Observed mentions: 2018-02-04 22:22:11 UTC to 2023-12-04 11:20:35 UTC.

0369122018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 6 mentions; 0 submissions, 6 comments20182019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 11 mentions; 0 submissions, 11 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 8 mentions; 0 submissions, 8 comments20202021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 7 mentions; 0 submissions, 7 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 5 mentions; 0 submissions, 5 comments2023

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC606
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC11011
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC808
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC707
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC202
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC505

What Hacker News says

39 sources
huijzer·Dec 4, 2023
> Yes, julia can be called from other languages rather easily This seems false to me. StaticCompiler.jl [1] puts in their limitations that "GC-tracked allocations and global variables do not work with compile_executable or compile_shlib. This has some interesting consequences, including that all functions within the function you want to compile must either be inlined or return only native types (otherwise Julia would have to allocate a place to put the results, which will fail)." In practice, this means that you can therefore not use the base library in your own programs. PackageCompiler.jl [2] has the same limitations if I'm not mistaken. So then you have to fall back to distributing the Julia "binary" with a full Julia runtime, which is pretty heavy. There are some packages, such as PySR [3], which do this. It seems pretty usable for re
Read the rest
search I'd say, but difficult to put in production. There is some word going around though that there is an even better static compiler in the making, but as long as that one is not publicly available I'd say that Julia cannot easily be called from other languages. [1]: https://github.com/tshort/StaticCompiler.jl [2]: https://github.com/JuliaLang/PackageCompiler.jl [3]: https://github.com/MilesCranmer/PySR
In Potential of the Julia programming language for high energy physics computing
eigenspace·Dec 4, 2023
Yes, julia can be called from other languages rather easily, Julia functions can be exposed and called with a C-like ABI [1], and then there's also various dedicated packages for languages like Python[2], R[3], C++[4], Rust[5] and more to call Julia code. With PackageCompiler.jl [6] you can even make AOT compiled standalone binaries, though these are rather large. They've shrunk a fair amount in recent releases, but they're still a lot of low hanging fruit to make the compiled binaries smaller, and some manual work you can do like removing LLVM and filtering stdlibs when they're not needed. Work is also happening on a more stable / mature system that acts like StaticCompiler.jl [7] except provided by the base language and people who are more experienced in the compiler (i.e. not a janky prototype) [1] https://docs.julialang.org/en/v1/manu
Read the rest
al/embedding/ [2] https://pypi.org/project/juliacall/ [3] https://www.rdocumentation.org/packages/JuliaCall/ [4] https://github.com/Clemapfel/jluna [5] https://github.com/Taaitaaiger/jlrs [6] https://github.com/JuliaLang/PackageCompiler.jl [7] https://github.com/tshort/StaticCompiler.jl
In Potential of the Julia programming language for high energy physics computing
markkitti·Nov 9, 2023
Julia 1.9's native precompilation is definitely helpful in that regard but loading those native shared libraries (.so files on Linux) into Julia does take some to verify. If the main objective is to reduce time to load and time to first task then PackageCompiler.jl [3] is still the ultimate way to do so. Because Julia is a dynamic language, there are some complicated compilation issues such as invalidation and recompilation that arise. Adding new methods or packages may result in already compiled code no longer statically dispatching correctly requiring invalidation and recompilation of that code. It slightly more complicated than what you stated. It's "I want to compile and cache native code for the following methods on the following types in this particular environment". PackageCompiler.jl can wrap the entire environment into a single n
Read the rest
ative library, the system image. [3] https://github.com/JuliaLang/PackageCompiler.jl
In SciPy builds for Python 3.12 on Windows are a minor miracle
ChrisRackauckas·Sep 12, 2022
I think by PackageManager here you mean package compiler, and yes these improvements do not need a 2.0. v1.8 included a few things to in the near future allow for building binaries without big dependencies like LLVM, and finishing this work is indeed slated for the v1.x releases. Saying "we are not doing a 2.0" is precisely saying that this is more important than things which change the user-facing language semantics. And TTFP does need to be addressed. It's a current shortcoming of the compiler that native and LLVM code is not cached during the precompilation stages. If such code is able to precompile into binaries, then startup time would be dramatically decreased because then a lot of package code would no longer have to JIT compile. Tim Holy and Valentin Churavy gave a nice talk at JuliaCon 2022 about the current progress of making th
Read the rest
is work: https://www.youtube.com/watch?v=GnsONc9DYg0 . This is all tied up with startup time and are all in some sense the same issue. Currently, the only way to get LLVM code cached, and thus startup time essentially eliminated, is to build it into what's called the "system image". That system image is the binary that package compiler builds (https://github.com/JuliaLang/PackageCompiler.jl). Julia then ships with a default system image that includes the standard library in order to remove the major chunk of code that "most" libraries share, which is why all of Julia Base works without JIT lag. However, that means everyone wants to have their thing, be it sparse matrices to statistics, in the standard library so that it gets the JIT-lag free build by default. This means the system image is huge, which is why PackageCompiler, which is simply a system for building binaries by appending package code to the system image, builds big binaries. What needs to happen is for packages to be able to precompile in a way that then caches LLVM and native code. Then there's no major compile time advantage to being in the system image, which will allow things to be pulled out of the system image to have a leaner Julia Base build without major drawbacks, which would then help make the system compile. That will then make it so that an LLVM and BLAS build does not have to be in every binary (which is what takes up most of the space and RAM), which would then allow Julia to much more comfortably move beyond the niche of scientific computing.
In Julia 2.0 isn’t coming anytime soon, and why that is a good thing
alhirzel·Apr 6, 2022
Revise.jl[1] is very helpful for development, as it allows for seamless recompilation without restarts. Cold start can also take a long time, so sometimes it helps to add options[2] such as -O0 when developing. Two paths forward for AOT compilation are PackageCompiler.jl[3] mentioned already in this thread (things like RelocatableFolders.jl[4] come in handy) and the possibility of GPUCompiler.jl[5] some day. [1]: https://github.com/timholy/Revise.jl [2]: https://docs.julialang.org/en/v1/manual/command-line-options... [3]: https://github.com/JuliaLang/PackageCompiler.jl [4]: https://github.com/JuliaPackaging/RelocatableFolders.jl [5]: https://github.com/JuliaGPU/GPUCompiler.jl/issues/3
In GenieFramework – Build web applications with Julia
staticfloat·Mar 25, 2021
We call these "system images" and you can generate them with PackageCompiler [0]. Unfortunately, it's still a little cumbersome to create them, but this is something that we're improving from release to release. One possible future is where an environment can be "baked", such that when you start Julia pointing to that environment (via `--project`) it loads all the packages more or less instantaneously. The downside is that generating system images can be quite slow, so we're still working on ways to generate them incrementally. In any case, if you're inspired to work on this kind of stuff, it's definitely something the entire community is interested in! [0] https://github.com/JuliaLang/PackageCompiler.jl
In Julia 1.6 Highlights
cbkeller·Mar 6, 2021
Currently the best you can do is to build a somewhat unwieldy relocatable “bundle” with PackageCompiler.jl [1], but there are apparently plans for actual static compilation using an approach more similar to that used in GPUCompiler.jl [2], and the latter approach should as far as I understand allow for the creation of proper .so/.dlls. [1] https://github.com/JuliaLang/PackageCompiler.jl [2] https://github.com/JuliaGPU/GPUCompiler.jl
In Symbolics.jl: A Modern Computer Algebra System for a Modern Language
smabie·Dec 6, 2020
Yeah, that's a good point. DataFrames.jl starts to really shine what the cookie cutter pandas functions arent adequate for what you need to do. DataFrames.jl can certainly be slower in some cases, but you should expect a consistent level of performance no matter what you do. This is a farcry from Pandas, which tanks by large factors when you start calling Python code vs C code. In regards to Julia's compilation problem, you can use https://github.com/JuliaLang/PackageCompiler.jl to precompile an image, allowing you to avoid paying the JIT performance penalty over and over again.
In R adds native pipe and lambda syntax

Showing the 15 most recent of 39 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.