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:36:16 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

markkitti·May 16, 2022

You could use Julia in an interpreted mode (or a compiler with low optimization) and then statically compile it for production. The JIT involved is really a static compiler that has been adapted for use as a JIT compiler: https://llvm.org/docs/ORCv2.html https://juliadebug.github.io/JuliaInterpreter.jl/stable/ https://julialang.github.io/PackageCompiler.jl/stable/apps.h... https://github.com/tshort/StaticCompiler.jl

In My Experiences with Julia

cbkeller·Feb 15, 2022

Yeah, not frowned upon at all. StaticCompiler.jl [1] has made huge strides in the past few weeks actually thanks to Mason and Valentin (swapping in GPUCompiler as the backend); you can even compile to a tiny standalone binary without linking to the runtime if you're willing to use some tricks e.g. [2] to avoid GC allocations (stack allocations and manual heap allocations are both fine): # This is all StaticCompiler-friendly using StaticTools function print_args(argc::Int, argv::Ptr{Ptr{UInt8}}) # c"..." lets you construct statically-sized, stack allocated `StaticString`s # We also have m"..." and MallocString if you want the same thing but on the heap printf(c"Argument count is %d:\n", argc) for i=1:argc # iᵗʰ input argument string pᵢ = unsafe_load(argv, i) # Get pointer

Read the rest

strᵢ = MallocString(pᵢ) # Can wrap to get high-level interface println(strᵢ) # No need to `free` since we didn't allocate this memory end println(c"That was fun, see you next time!") return 0 end # Compile executable using StaticCompiler # `] add https://github.com/tshort/StaticCompiler.jl` to get latest master filepath = compile_executable(print_args, (Int64, Ptr{Ptr{UInt8}}), "./") yielding: shell> ./print_args 1 2 3 4 5.0 foo Argument count is 7: ./print_args 1 2 3 4 5.0 foo That was fun, see you next time! shell> hyperfine './print_args hello there' Benchmark 1: ./print_args hello there Time (mean ± σ): 2.2 ms ± 0.5 ms [User: 0.8 ms, System: 0.0 ms] Range (min … max): 1.5 ms … 5.5 ms 564 runs Warning: Command took less than 5 ms to complete. Results might be inaccurate. shell> ls -lh print_args -rwxr-xr-x 1 user staff 8.5K Feb 10 02:36 print_args GC allocations are allowed if you use instead the approach in this PR [3], but we haven't wrangled that approach to produce standalone binaries yet. [1] https://github.com/tshort/StaticCompiler.jl [2] https://github.com/brenhinkeller/StaticTools.jl [3] https://github.com/tshort/StaticCompiler.jl/pull/58

In Why We Use Julia, 10 Years Later

cbkeller·Feb 15, 2022

And the "how" behind Octavian.jl is basically LoopVectorization.jl [1], which helps make optimal use of your CPU's SIMD instructions. Currently there can some nontrivial compilation latency with this approach, but since LV ultimately emits custom LLVM it's actually perfectly compatible with StaticCompiler.jl [2] following Mason's rewrite, so stay tuned on that front. [1] https://github.com/JuliaSIMD/LoopVectorization.jl [2] https://github.com/tshort/StaticCompiler.jl

In Why We Use Julia, 10 Years Later

eigenspace·Feb 14, 2022

Yeah, it's definitely in the early stages still, but this time I think there's much more infrastructure, and more people around with the right knowledge to advise on StaticCompiler's development, that I'm currently feeling pretty good about it's future. Here's the feature roadmap https://github.com/tshort/StaticCompiler.jl/issues/59 that should help people understand what currently works and what I think I can reasonably accomplish eventually

In Why We Use Julia, 10 Years Later

ChrisRackauckas·Feb 14, 2022

StaticCompiler.jl is making huge strides. 12 days ago a rewrite was merged (https://github.com/tshort/StaticCompiler.jl/pull/46), and now the static compiler can allocate and use the runtime (https://github.com/tshort/StaticCompiler.jl/pull/58). I would still be weary of using it too much, but hopefully optimistic of its near future.

In Why We Use Julia, 10 Years Later