Julia as a backend language in R, Python, and browsers (WASM)

Internals & Design
1

Hello everyone,

I hope I am not duplicating another open thread with these questions. (I have older posts about Juliac and lowering Julia code but I think this post has some new extensions after 1-2 years).

I am writing this post both to keep myself informed and updated on the current state of affairs, and to bring to light any aspects that might have been overlooked.

A few years ago, survey results clearly showed that compiling Julia code into standalone executables and dynamic libraries was a top priority, and the Julia Core Team began working on this. If I recall correctly, around this time last year, developing the juliac infrastructure into a deployable application was a major milestone. For the past six months, I have also been seeing the terms “trimming” and “lowering” appear very frequently in Julia’s commit history. I would like to express my sincere gratitude to everyone contributing to these visible efforts. The ongoing work to strip down the runtime of a dynamic language like Julia as much as possible is truly admirable.

Currently, there are packages available to call Julia in the background, allowing us to embed Julia code within R and Python packages. However, this approach still requires a full Julia installation. Because we still face the same hurdles as running a regular Julia script-such as the infamous first-time startup latency and the time-consuming initial setup-this approach is not yet as seamless or practical as, for example, calling C++ from R.

We can see from various surveys and language ranking sites that Julia is gradually expanding its footprint as an independent language. I am fully aware that packages like RCall and PythonCall offer great convenience to users coming from other languages. However, it is very clear that Julia must also evolve into a language that provides functionality to these other languages, much like Fortran and C++ do. As some Julia developers have put it, this feels like a matter of survival. To significantly grow Julia’s market share, we need to be able to practically distribute Julia-powered .dll/.so/.dylib files to other languages.

In the meantime, WebAssembly (WASM) has also matured rapidly over the last few years. In my view, the need for Julia to have a presence on the web has become increasingly vital. Fortunately, the ongoing work on juliac inherently supports WebAssembly targets in parallel. In other words, two crucial goals-generating small executables and emitting WebAssembly code-have converged into a single unified effort.

This brings me to what I am most curious about: When will we be able to easily ship Julia libraries behind Python and R packages? And a parallel question: When will we be able to compile our Julia code to the browser as naturally as Rust does? Is there a projected timeline or a target version for this? Years ago, these features were viewed as a luxury, but today it feels like a make-or-break issue for the language. Do you agree?

With my best regards and respect to all community members.

2

You already can use juliac to produce a library that can be used as you’d expect. And I also believe that there are already some python packages that underneath are calling differential equation solvers written in Julia.

Of course the type of code needed for trimming to succeed requires much more strictness’s and precision and can’t be as dynamic.

Regarding WASM there are some experiments going on. I know of WASMTarget.jl and Whisk.jl, both seem very promising.

3

Thank you for the insightful reply and for pointing out WASMTarget.jl. Is indeed very exciting experiments. I haven’t used the other mentioned package, yet.

However, I believe there are still two critical bottlenecks keeping us from achieving a truly independent backend status, both of which stem from the lingering presence of the dynamic runtime:

  1. The Shared Library Dependency: While juliac can compile a library, running an ldd command on the resulting binary reveals that it is still heavily linked against Julia’s core shared libraries (like libjulia). It isn’t a completely self-contained, standalone asset that you can just drop into any system like a pure C or Rust binary (Static versus Dynamic Compilation). I think my post was a little bit erroneously, I should have written .a and .lib instead of .dll and .so or a dynamic library that depends on the essential libraries such like libc only.

  2. Ecosystem Limitations in WASM: Tools like WASMTarget.jl work beautifully for basic, isolated code. However, the moment you try to compile real-world, external packages from the ecosystem, the compilation breaks down.

As you mentioned, the strictness required for trimming is immense. Until we can cleanly decouple external packages from the dynamic features of the core runtime, using Julia as a seamless, lightweight backend for other languages and browsers will remain a challenge.

I’m very curious to see if the core team will address these specific limitations during JuliaCon 2026!