# 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:** 1\
**Showing post:** 4

<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).

---

_[View the full topic](https://discourse.julialang.org/t/question-about-the-future-of-juliac/129228)._