With respect to GPU programming, we have std::offload for vendor-agnostic GPU programming under development, as well as a few out-of-tree solutions (Cutile-rs and oxide-cuda from nvidia), rust-cuda and rust-gpu (spirv), and in-tree amd+nvidia gpu targets (intel is under development). We’ve benchmarked offload on RajaPerf, and got the same memory consumption and runtime as cuda implementations. Obviously, none of these solutions is nearly as mature as KA.jl or some of the other nice Julia equivalents.
With respect to language stability, Rust has Editions and crater as two very helpful features. We can deprecate/remove/fix some of our past mistakes via editions without breaking user code. We also use GitHub - rust-lang/crater: Run experiments across parts of the Rust ecosystem! · GitHub to test a possibly breaking PR (as well as releases, I’d guess) by compiling every test on every crate that was published on our package manager. If a bugfix to rustc breaks existing crates, then compiler devs will usually reach out to the package maintainers and work on a fix before the PR hits the next stable release. We also have an extensive compile-time, and a small runtime benchmark suite, that we run on every pr that gets merged into rustc. Anything regressing either tends to be directly reverted, unless it’s well motivated. We also have a weekly performance triage to notice performance changes over a larger window: rustc-perf/triage/2026/2026-06-01.md at 4a082d37cfd5006c8313e55bab306ea41f091714 · Kobzol/rustc-perf · GitHub
I am not sure, though, how helpful or doable such solutions would be for julia development.