# Question about the future of JuliaC

**URL:** <https://discourse.julialang.org/t/question-about-the-future-of-juliac/129228>\
**Category:** Community\
**Tags:** compilation\
**Created:** [May 21, 2025, 5:24pm UTC](https://discourse.julialang.org/t/question-about-the-future-of-juliac/129228 "2025-05-21T17:24:43Z")\
**Posts on this page:** 11\
**Page:** 1

<div class="post-metadata">

**Author:** ![Matt\_jl](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/matt_jl/32/52364_2.png) [@Matt\_jl](https://discourse.julialang.org/u/Matt_jl)\
**Post date:** [May 21, 2025, 5:24pm UTC](https://discourse.julialang.org/t/question-about-the-future-of-juliac/129228/1 "2025-05-21T17:24:43Z")

</div>

Hi everyone,

I’m definitely not a professional programmer and I don’t have a degree in computer engineering, so please forgive any naive questions — this post comes purely from curiosity.

I’ve been using Julia for research for a few years now, and I have some experience with compiled languages like C++ and Fortran. Lately, I’ve noticed a lot of discussion around efforts to create a native compiler for Julia — in particular, I’m referring to _juliac_.

Unfortunately, I couldn’t find much up-to-date information about its current state, so I was hoping the community could shed some light on the status and direction of this project.

I also have a beginner-level question that I’m hoping someone can clarify. From what I understand, the idea (at least for now) is that it will be possible to compile Julia code _only if_ there are no heap allocations or external runtime dependencies. That is, the runtime and garbage collector won’t be included in the final executable.

Why is this the case? Is it due to fundamental limitations in the language design? Or is this just a first step toward a future where a more complete Julia runtime might be included in the compiled output?

Thanks!

---

<div class="post-metadata">

**Author:** ![Oscar\_Smith](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/oscar_smith/32/25343_2.png) [@Oscar\_Smith](https://discourse.julialang.org/u/Oscar_Smith)\
**Post date:** [May 21, 2025, 5:33pm UTC](https://discourse.julialang.org/t/question-about-the-future-of-juliac/129228/2 "2025-05-21T17:33:26Z")

</div>

> I also have a beginner-level question that I’m hoping someone can clarify. From what I understand, the idea (at least for now) is that it will be possible to compile Julia code _only if_ there are no heap allocations or external runtime dependencies

This isn’t correct. Juliac supports allocations (and the runtime is provided by the Julia binary like normal)

---

<div class="post-metadata">

**Author:** ![Matt\_jl](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/matt_jl/32/52364_2.png) [@Matt\_jl](https://discourse.julialang.org/u/Matt_jl)\
**Post date:** [May 21, 2025, 5:36pm UTC](https://discourse.julialang.org/t/question-about-the-future-of-juliac/129228/3 "2025-05-21T17:36:37Z")

</div>

aah didn’t get it. thank you!

---

<div class="post-metadata">

**Author:** ![mbauman](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mbauman/32/31082_2.png) [@mbauman](https://discourse.julialang.org/u/mbauman)\
**Post date:** [May 21, 2025, 5:45pm UTC](https://discourse.julialang.org/t/question-about-the-future-of-juliac/129228/4 "2025-05-21T17:45:50Z")

</div>

Yeah, this can be a little confusing. There are quite a few different ways of running Julia and more are coming.

- There’s the `julia` REPL. It’s already a native compiler! As you type in Julia code, it’ll get compiled to your architecture on the fly! Of course not a very great distribution mechanism.
- There’s `julia script.jl`. Julia will parse the `script` and similarly generate native code on the fly. But again, every time you run this, it’ll _re-do_ the compilation work.
- There’s `julia --project=@script script.jl` that’ll use the packages defined in the `Project.toml` that appears alongside the script. These packages will precompile the first time you instantiate them — down to native code! And then all those packages — particularly if they use PrecompileTools.jl — will preemptively cache native code for you, so Julia only needs to on-demand compile the stuff that appears in `script.jl` or is missing from the package precompiles. But of course distributing this is still hard — it’s not “just” an `.exe` (or equivalent).
- There’s PackageCompiler.jl, which can create a native executable given a particular set of packages and workflow. This can make distributing much easier! But… it gathers up _everything_ you might _possibly_ call. It’s _slow_ and _big_. The outputs in the hundreds of MB or even GB range.
- Then, finally, there’s `juliac` and in particular `juliac --experimental --trim`. These are still experimental, but the latter will trim out everything you _don’t_ call, leading to much more reasonable executable sizes. The big limitation on getting a small binary is with type stability, not allocations — if things aren’t type stable, Julia won’t be able to predict what methods you’ll need to compile. The best place to see info here is in live talks; see Jeff at [JuliaCon 2024](https://www.youtube.com/watch?v=R0DEG-ddBZA&pp=ygUGanVsaWFj0gcJCY0JAYcqIYzv) and [PyData 2024](https://www.youtube.com/watch?v=LluyXFj9YDI).

---

<div class="post-metadata">

**Author:** ![yolhan\_mannes](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/yolhan_mannes/32/220485_2.png) [@yolhan\_mannes](https://discourse.julialang.org/u/yolhan_mannes)\
**Post date:** [May 21, 2025, 5:49pm UTC](https://discourse.julialang.org/t/question-about-the-future-of-juliac/129228/5 "2025-05-21T17:49:05Z")

</div>

There is also StaticCompiler.jl which has the heap allocations limitations (and others).

---

<div class="post-metadata">

**Author:** ![Matt\_jl](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/matt_jl/32/52364_2.png) [@Matt\_jl](https://discourse.julialang.org/u/Matt_jl)\
**Post date:** [May 21, 2025, 6:10pm UTC](https://discourse.julialang.org/t/question-about-the-future-of-juliac/129228/6 "2025-05-21T18:10:39Z")

</div>

thank you!

---

<div class="post-metadata">

**Author:** ![xiaoxi](https://avatars.discourse-cdn.com/v4/letter/x/a9adbd/32.png) [@xiaoxi](https://discourse.julialang.org/u/xiaoxi)\
**Post date:** [May 21, 2025, 6:43pm UTC](https://discourse.julialang.org/t/question-about-the-future-of-juliac/129228/7 "2025-05-21T18:43:48Z")

</div>

> [@mbauman](#):
>
> Yeah, this can be a little confusing. There are quite a few different ways of running Julia and more are coming.

I wonder to what extent a Julia-lang blog post on the pros and cons of the different ways to run Julia would be useful. It’s getting harder and harder to keep track of all them.

---

<div class="post-metadata">

**Author:** ![sylvaticus](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/sylvaticus/32/203883_2.png) [@sylvaticus](https://discourse.julialang.org/u/sylvaticus)\
**Post date:** [May 22, 2025, 8:30am UTC](https://discourse.julialang.org/t/question-about-the-future-of-juliac/129228/8 "2025-05-22T08:30:47Z")

</div>

To note that the `trim` option is in the upcoming julia 1.12 version…

---

<div class="post-metadata">

**Author:** ![hexaeder](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/hexaeder/32/24403_2.png) [@hexaeder](https://discourse.julialang.org/u/hexaeder)\
**Post date:** [May 22, 2025, 8:52am UTC](https://discourse.julialang.org/t/question-about-the-future-of-juliac/129228/9 "2025-05-22T08:52:41Z")

</div>

> [@mbauman](#):
>
> The big limitation on getting a small binary is with type stability

What happens if your code isn’t completely typestable / contains dynamic dispatch? Is this code then out of scope for `juliac`? Or will it do a best effort but you won’t get very small binaries? Or can the user provide something similar to a precompile workload and promise the compiler that there won’t be any other method calls (accepting runtime errors otherwise)?

---

<div class="post-metadata">

**Author:** ![jules](https://avatars.discourse-cdn.com/v4/letter/j/41988e/32.png) [@jules](https://discourse.julialang.org/u/jules)\
**Post date:** [May 22, 2025, 9:05am UTC](https://discourse.julialang.org/t/question-about-the-future-of-juliac/129228/10 "2025-05-22T09:05:37Z")

</div>

I think juliac has a heuristic cutoff for when it considers a call site to be “too dynamic”, so some amount of dynamic dispatch is allowed, but the set of possible callees cannot be unbounded. It’s like the small union optimization where `Union{Nothing,Something}` is also not considered type-unstable per se.

---

<div class="post-metadata">

**Author:** ![nsajko](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/nsajko/32/221187_2.png) [@nsajko](https://discourse.julialang.org/u/nsajko)\
**Post date:** [May 22, 2025, 9:05am UTC](https://discourse.julialang.org/t/question-about-the-future-of-juliac/129228/11 "2025-05-22T09:05:53Z")

</div>

> [@sylvaticus](#):
>
> To note that the `trim` option is in the upcoming julia 1.12 version…

Trimming is still experimental though AFAIK. And v1.12 is in the feature freeze part of the release cycle.