What does HackerNews think of StaticCompiler.jl?
Compiles Julia code to a standalone library (experimental)
On garbage collection and real-time applications, there is this [2] talk where ASML (the manufacturer of photolithography machines for TSMC) uses Julia for it. Basically it preallocates all memory needed before hand and turns off the garbage collector.
On the same more about real-time, if your call stack is all type stable [3], the you can be sure that after the first call (and subsequent compilation), the JAOT compiler won't be triggered.
About static compilation, there are two different approaches * PackageCompiler.jl [4], which is rally stable and used in production today. It has he downside of generating huge executables, but you can do work to trim them. There is still work to do on the size of them. * StaticCompiler.jl [5], which is still in the experimental phase. But it is far from being completely brittle. It does puts several restrictions on the chide you can write and compile with it, basically turning Julia in a static type language. But it had been successfully used to compile linkable libraries and executables.
Some of the concerns you have about usability in your third paragraph have been worked on with the 1.9 and 1.10 (coming) releases. The LSP usage is better thanks to native code caching, maybe you can try it again (of you have time). The debugging experience I honestly think is top notch if you're using Debugger.jl+Revise.jl [6] [7], still I know there are some caveats in it. About stack traces, there is also a more of work done to make them better and more readable, you can read the with done in these PR's [8] [9] [10] [11, for state of Julia talk].
Still, I can understand that Julia might not be able (yet) to cover all the usecases or workflows of different people.
[1]: https://julialang.org/blog/2023/04/julia-1.9-highlights/#cac... [2]: https://www.youtube.com/watch?v=EafTuyy7apY [3]: https://docs.julialang.org/en/v1/manual/performance-tips/#Wr... [4]: https://julialang.github.io/PackageCompiler.jl [5]: https://github.com/tshort/StaticCompiler.jl [6]: https://github.com/JuliaDebug/Debugger.jl [7]: https://timholy.github.io/Revise.jl/stable/ [8]: https://github.com/JuliaLang/julia/pull/49117 [9]: https://github.com/JuliaLang/julia/pull/49959 [10]: https://github.com/JuliaLang/julia/pull/45069 [11]: https://www.youtube.com/watch?v=2D8oRtDJEeg&t=2487
The immature AoT capabilities are a huge pain to deal with when writing large code packages or even when trying to make command line applications. Things have to be recompiled each time the Julia runtime is shut down. The current strategy in the community to get around this seems to be "keep the REPL alive as long as possible" [3][4][5], but this isn't a viable option for all use cases.
Until Julia has better AoT compilation support, it's going to be very difficult to develop large scale programs with it. Version 1.9 has better support for caching compiled code, but I really wish there were better options for AoT compiling small, static, standalone executables and libraries.
[1]: https://julialang.github.io/PackageCompiler.jl/dev/
[2]: https://github.com/tshort/StaticCompiler.jl
[3]: https://discourse.julialang.org/t/ann-the-ion-command-line-f...
[4]: https://discourse.julialang.org/t/extremely-slow-execution-t...
[5]: https://discourse.julialang.org/t/extremely-slow-execution-t...
[6]: https://www.reddit.com/r/Julia/comments/ytegfk/size_of_a_hel...
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