Are you actually sure it's solved? I note that Julia proponents have a history of claiming that an issue has been solved when it is apparent that it has not been solved (see e.g. https://danluu.com/julialang/).
The events of my post happened in the last two months on Julia version 1.11.5, and this poster simply linked to a primer on PackageCompiler.jl which is the thing I said I was using in my post. It's not solved; at best there are complicated mitigations that let you control when the long compilation happens without avoiding it. If you try out Julia, you will run into the issue, and as a first-time user you won't be prepared to implement the mitigations, none of which are suitable for ad hoc usage. The sysimage only works for us because we rarely change our packages so we can build it ahead of time in GitHub Actions.
The tradeoff between compilation time and programmer productivity and running speed is worth it compared with using any other language. You should consider most users don' t need to build an image . They just do things in the REPL with Revise.jl (which is fast). Or use a bit of PrecompileTools.jl to get good enough startup time (which isn' t complicated if you are the code writer). Package compiling works even large and slow is a bonus. https://pypl.github.io/PYPL.html Julia still grows despite all those controversial articles for a reason.
I'll speak as someone who began as a Julia skeptic, but now finds it invaluable for my day-to-day work. Here are some reasons why you might prefer Rust today:
- Julia's lack of formal interface specification. Julia gets a lot of flexibility from its multi-method dispatch. This feature is often considered a major selling point in allowing code reuse. Many Julia packages in the ecosystem can be combined in a way that "just works". Consider, for example, combining CuArrays.jl with KrylovKit.jl to get GPU acceleration of sparse iterative solvers (https://github.com/Jutho/KrylovKit.jl/issues/15). But it's not always clear who actually "owns" such integrations. Because public interfaces aren't always well documented in Julia, things are prone to breakage, and it can sometimes feel like "action at a distance". This was especially painful with the OffsetArrys.jl package, which suddenly introduced arrays that could begin at any integer index. (That was the major theme of Yuri's blog post, and the simple solution for most people was to avoid OffsetArrays.) Rust's community philosophy and formal trait system err on the side of providing static guarantees for correctness. But these constraints also take away flexibility to fit distinct packages together. For example, Julia has always had excellent support for type specialization, and this has been notoriously challenging to fit into Rust, even in a very limited form: https://users.rust-lang.org/t/the-state-of-specialization/11.... Conversely, there have been many discussions about designing a formal interface system in Julia, but it remains a challenge: https://discourse.julialang.org/t/proposal-adding-optional-s...
- Julia is designed around just-in-time compilation. For example, every time a function is called with new argument types, it will be freshly compiled for that specialization. This is great when you care about getting optimal performance. Also, because Julia allows to reify syntax as value-level objects, you can assemble Julia code that is custom optimized to run-time values. All of this is amazingly powerful for certain kinds of number crunching codes. But carrying around a full LLVM system is clearly a blocker for distributing small, precompiled binaries. Hence the LWN discussion about the preview juliac feature, which will offer a mode for fully static compilation.
- Rust's borrow checker is something to envy. In any other language, I miss the ability to safely passing around references to stack allocated variables, or to know that a referenced value cannot be mutated.
Finally, I would probably recommend Python (not Rust!) for most machine learning or data analysis projects that aren't too "bespoke". There's just so much momentum behind PyTorch and JAX. The Julia community is developing some very interesting packages in this space. Notably, Lux.jl, Enzyme.jl, Reactant.jl, and all of SciML. These are super powerful, but still very researchy. For simple things, Python will probably be less friction.
The best language will depend on your use case. Julia serves its niche very well, even if it doesn't fit every possible use case.
Can you expand on the intriguing comment that “because Julia allows to reify syntax as value-level objects, you can assemble Julia code that is custom optimized to run-time values” (ideally with an example)?
