It is possible to call Rust (dynamic) libraries from Julia, with ccall keyword. It implies C-like API of your Rust code used (or Fortran, or C++, or well C) used.
I.e. you need to add extern "C" to functions you call (and possibly also use #[repr(C)], i.e. for Rust structs, but I think you don’t need to do that always, even never, i.e. if they are not involved in interop).
https://docs.rust-embedded.org/book/interoperability/c-with-rust.html
I believe e.g. this is an example of that Polars.jl.
It IS also possible to call Rust from Julia (at least up to 1.10 LTS and 1.11), i.e. embed Julia in Rust, with a package for that, like you can embed Julia into Python, R etc.
I believe in the developer since the package (that I haven’t used) seems very well documented and well received, and has supported across many Julia versions with it’s “unstable C API”.
E.g. the internal C [non-]API of Julia was broken with 1.11, why juliacall for R is in a bit of trouble with a trivial fix though.
The package for Rust is not in trouble, I see it was fixed for 1.11, and is tested for it:
Array functions that have been removed in Julia 1.11, like
jl_reshape_array, have been removed completely. Call the Julia function instead.
I wouldn’t worry about being able to call Julia from Rust, since you can stay with 1.10 LTS version, that was very recently declared, and thus will be supported for (I assume) the next 3+ years. If 1.12+ breaks something I’m confident it will be fixed in interop packages, but if you’re really worried about maintainers going missing then you have at least 1.10 and 1.11 to call, and Rust is a very important language that I’m sure someone would take over.
I note it’s not yet possible to call Python 3.13 from Julia (nor call from it likely), I filed an issue, it seems Python might have broken its API, or if not PythonCall.jl relied on internals. Python does have a stable API (also another level limited API, then internals, unstable, and they are changing unusually many now).
See also: