rust

I am a maintainer. I think what you're referring to is the problem where `std` is actually a veneer on C - so for example, when Rust allocates memory on an x86-class desktop, it actually invokes a C library (jemalloc, or whatever the OS is using) and that networking is all built on top of libc. Thus a bunch of nice things like threads, time, filesystem, allocators are all actually the same old C libraries that everything else uses underneath a patina of Rust. In Xous, considerable effort went in to build the entire `std` in Rust as well, so no C compilers are required to build the OS, including `std`. You can see some of the bindings here in the Rust fork that we maintain: https://github.com/betrusted-io/rust/tree/1.92.0-xous/librar... Thus to boot the OS, a few lines of assembly are required to set up the stack pointer and some default e

This is correct. When you tell someone to install Rust, they go to rustup.rs and install the latest version. Therefore, we need to have a libstd port for the latest version. Which effectively means we need to release libstd as soon as possible after the compiler is released. Our `sys` directory is at https://github.com/betrusted-io/rust/tree/1.61.0-xous/librar... and isn't too complicated. It's about 50 patches that need to be carried forward every six weeks. Fortunately libstd doesn't change too much, at leaset not the parts we need. And I can usually pre-port the patches by applying them to `beta`, which means the patches against the release version usually apply cleanly. It's still better than requiring nightly, which has absolutely no stability guarantees. By targeting stable, we don't run into issues of bitrot where we accidentally r