tshort

StaticCompiler.jl

Julia2021–2025

tshort / StaticCompiler.jl

StaticCompiler.jl

Compiles Julia code to a standalone library (experimental)

Libraries & SDKs

Explore on GitHub Read Hacker News discussions

12Distinct people

19Mentions

0Explicit recommenders

560GitHub stars

REPOSITORY AT A GLANCE

What to know before exploring

What it is

Compiles Julia code to a standalone library (experimental)

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

julialang/packagecompiler.jl · linked in 2 of the same discussions

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

This week on Hacker News

Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 6:01:32 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 year19 dated mentions

Observed mentions: 2021-03-25 21:35:42 UTC to 2025-11-27 06:00:44 UTC.

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.
Period	Start (UTC)	End (exclusive, UTC)	Mentions	Comments
2021	2021-01-01 00:00:00 UTC	2022-01-01 00:00:00 UTC	7	7
2022	2022-01-01 00:00:00 UTC	2023-01-01 00:00:00 UTC	5	5
2023	2023-01-01 00:00:00 UTC	2024-01-01 00:00:00 UTC	5	5
2024	2024-01-01 00:00:00 UTC	2025-01-01 00:00:00 UTC	0	0
2025	2025-01-01 00:00:00 UTC	2026-01-01 00:00:00 UTC	2	2

What Hacker News says

5 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

suavesito·Sep 9, 2023

About the show startup times, they have been worked massively in the latest version of Julia. Mainly in version 1.9, which is the first version of Julia that saves native compiled code. You can RAAF more about that in the released blog [1]. On garbage collection and real-time applications, there is this [2] talk where ASML (the manufacturer of photolithography machines for TSMC) uses Julia for it. Basically it preallocates all memory needed before hand and turns off the garbage collector. On the same more about real-time, if your call stack is all type stable [3], the you can be sure that after the first call (and subsequent compilation), the JAOT compiler won't be triggered. About static compilation, there are two different approaches * PackageCompiler.jl [4], which is rally stable and used in production today. It has he downside of gen

Read the rest

erating huge executables, but you can do work to trim them. There is still work to do on the size of them. * StaticCompiler.jl [5], which is still in the experimental phase. But it is far from being completely brittle. It does puts several restrictions on the chide you can write and compile with it, basically turning Julia in a static type language. But it had been successfully used to compile linkable libraries and executables. Some of the concerns you have about usability in your third paragraph have been worked on with the 1.9 and 1.10 (coming) releases. The LSP usage is better thanks to native code caching, maybe you can try it again (of you have time). The debugging experience I honestly think is top notch if you're using Debugger.jl+Revise.jl [6] [7], still I know there are some caveats in it. About stack traces, there is also a more of work done to make them better and more readable, you can read the with done in these PR's [8] [9] [10] [11, for state of Julia talk]. Still, I can understand that Julia might not be able (yet) to cover all the usecases or workflows of different people. [1]: https://julialang.org/blog/2023/04/julia-1.9-highlights/#cac... [2]: https://www.youtube.com/watch?v=EafTuyy7apY [3]: https://docs.julialang.org/en/v1/manual/performance-tips/#Wr... [4]: https://julialang.github.io/PackageCompiler.jl [5]: https://github.com/tshort/StaticCompiler.jl [6]: https://github.com/JuliaDebug/Debugger.jl [7]: https://timholy.github.io/Revise.jl/stable/ [8]: https://github.com/JuliaLang/julia/pull/49117 [9]: https://github.com/JuliaLang/julia/pull/49959 [10]: https://github.com/JuliaLang/julia/pull/45069 [11]: https://www.youtube.com/watch?v=2D8oRtDJEeg&t=2487

In Julia and Mojo Mandelbrot Benchmark

xgdgsc·Jun 4, 2023

https://github.com/tshort/StaticCompiler.jl/issues/59 Would working on this feasible?

In Building a Lox Interpreter in Julia

ubj·Mar 30, 2023

One of Julia's Achilles heels is standalone, ahead-of-time compilation. Technically this is already possible [1], [2], but there are quite a few limitations when doing this (e.g. "Hello world" is 150 MB [6]) and it's not an easy or natural process. The immature AoT capabilities are a huge pain to deal with when writing large code packages or even when trying to make command line applications. Things have to be recompiled each time the Julia runtime is shut down. The current strategy in the community to get around this seems to be "keep the REPL alive as long as possible" [3][4][5], but this isn't a viable option for all use cases. Until Julia has better AoT compilation support, it's going to be very difficult to develop large scale programs with it. Version 1.9 has better support for caching compiled code, but I really wish there were bet

Read the rest

ter options for AoT compiling small, static, standalone executables and libraries. [1]: https://julialang.github.io/PackageCompiler.jl/dev/ [2]: https://github.com/tshort/StaticCompiler.jl [3]: https://discourse.julialang.org/t/ann-the-ion-command-line-f... [4]: https://discourse.julialang.org/t/extremely-slow-execution-t... [5]: https://discourse.julialang.org/t/extremely-slow-execution-t... [6]: https://www.reddit.com/r/Julia/comments/ytegfk/size_of_a_hel...

In Making Python faster with Rust