I couldn’t agree more. These threads have got me thinking and revisiting prior threads and talks about why we want trimming and small binaries. In a desktop tools context, where I’m delivering something developed in Julia to non-Julia users, asking them to install Julia is a non-starter (and may frankly not even be allowable in some environments). Also, given that trimming only seems to reduce the binary itself (great if your use case is low-SWAP embedded targets), but not the many times larger collection of runtime dependencies, it actually doesn’t seem to be doing much for the desktop use case. If anything, since we don’t have cross-compilation, it makes things less portable (and let’s not forget that I also have to give up parts of Julia in order to be strict and (gradually) rewrite my code to even get there… sorry, that’s very much two languages and serious desktop tool deployment friction).
Hello World is about ~120MB on Windows with --trim, which, compared to Electron and other hybrid alternatives, isn’t too bad. Given the compromises you will have to make across the board, this makes me far less interested in trimming and static compilation for the desktop tool use case.
And, again, shoutout to AppBundler.jl for providing options here. I’d love to see some benchmarks for size and performance vs tradeoffs under different option sets for desktop deployments using it.
You make a valid point, but I am wondering if expecting these things from Julia is reasonable in the medium run, or at all.
Recall that Julia started as an interactive language for scientific programming, that allows the users to progress from quick prototypes to performant code within the same language. It has done admirably, and is getting better at this day by day.
But what it wasn’t designed for is all of the things you mention. With enough resources, a lot of things are doable, but Julia does not have infinite resources. And some things are just impossible to retrofit into language while keeping it compatible with itself, just like one cannot simply reimplement, say, Python to be like Julia while keeping it compatible with existing code.
So, while I follow the progress if trimming etc with interest, and I am aware that there are ingenious people among the developers who can pull off amazing feats, if I had to choose between keeping Julia convenient & fast for interactive sessions, and small trimmed binaries etc, I would choose the former. (I am still seriously hoping that I won’t have to choose.)
There are historical examples of trying aggresively compiling/optimizing/trimming programs in an interpreted language using whole program flow and escape analysis. Eg for Scheme, Stalin and Chez Scheme tried this. My understanding is that these approaches only scale up to a point, but maybe Julia is different.
I don’t really agree. @GeorgeGkountouras is right that ‘“Deploy” can mean different thing for different people’ - in my neck of the scientific woods, scientific software is typically run in one of two ways: Interactively, e.g. in a notebook, or as executables from command line. Julia is good at the former, and not so good at the latter.
For the latter, until very recently, I would need to tell users to:
- Download and install Julia
- Open Julia (with
--startup=no, in case they already have a Julia startup file) - Use the package manager to make a new environment
- Install my package in that environment
- Wait for precompilation
All this requires maybe a 1 GB download, and minutes of compilation time, not to mention learning how to use the Julian package manager.
Then, to launch the program, I’d need a separate script to run the package, which would need to be invoked with: julia --project=@project_name --startup=no script.jl <ARGS>
Compare to Rust, where the instructions are
- Figure out your computers’ OS and architecture
- Download the corresponding executable
- Run
myprogramfrom command line
The ideal for trimmed binaries is to get to the point where Rust is. Recent developments have made the Julia situation much better. Now, I can ask people to:
- Install Julia
- Add the
~/.julia/binto PATH if not already - Run
julia -e 'using Pkg; Pkg.Apps.add(; url="http://my_repo.jl")' - Run
myprogramfrom command line
Much better! But still a problem with huge download sizes, large precompile times, and latency when running the program. Note that these are, in my eyes, all “deployment” problems: The program is difficult to actually run.
But does it actually matter when doing scientific computation? Yes, in my opinion. Big files, slow downloads and installs, and sluggish programs make Julia much less attractive to use Julia for programs that function as a single step in e.g. a Snakemake workflow.
I know distributing precompilation files has come up a lot of over the years (eg here), but I think the apps case is a lot cleaner than the general case and might help a lot here, since an app can have a locked-down manifest so there should be fewer issues with precompilation files getting invalidated.
This has also been discussed elsewhere, but it should be feasible to get these 4 steps down to 2 like uvx has. There you install uv, then you uvx myprogram ... and that’s it.
If we had that, and it magically downloaded the appropriate precompilation files, and the app had a good precompilation script, maybe we can resolve all of those pain points points decently well besides “huge download sizes” without trimming.