Has the Executorch team ever considered using the Rust programming language for the runtime before? C++ was chosen because it is friendly for embedded systems, but I think Rust might also be a good choice for the same reason.
I would be interested to hear the reasoning behind the decision!
C++ was chosen because it is friendly for embedded systems
This is the biggest reason: C++ has the most toolchain support across embedded architectures, and is also viable for mobile/desktop use. But also, ExecuTorch interacts with existing C++ types and libraries provided by the core PyTorch project.
I think that it’d be interesting to write the core runtime in Rust, especially for safer .pte file parsing. But the core runtime is only a small piece: there are hundreds of C++ kernel implementations, as well as a growing number of C++ backend implementations. I don’t expect that we’d replace all of those. And Rust today can’t call C++ (because of C++'s poorly-defined ABI), so we’d need some kind of Rust-to-C-to-C++ wrapper layer in there.
If someone wanted to play around with Rust in executorch, I think that starting with some kernels would be a good experiment. Kernel implementations might benefit from Rust’s macros, and would definitely benefit from its memory safety. The core runtime loop expects to call a C++ function pointer, but that function could point to a C++ wrapper that then calls into Rust. Some of the biggest work would be to write adapters for the ExecuTorch EValue types (like Tensor), since the kernel code would need to read and write those types.
If anyone is interested in using Executorch from Rust, I wrote a bindings crate for it, implemented the mentioned Rust-to-C-to-C++ layer.
https://github.com/barakugav/executorch-rs