I think there is a space for other alternative low-level languages that aren't that strict about compile-time safety though (Zig, Jai, Odin), that Rust cannot capture.
Many proclaim that compile-time safety using type theory is the only way to create reliable low-level software, but I think it can alternatively be done with good data structure design and various compiler tooling that instead catch these errors at runtime (generational indices/references, Address Sanitizer, and recently Zig's safety mode). We need to explore multiple directions to really solve the memory safety problem, and I don't think Rust is the only way (although it is a viable way, proven by some recent successful applications).
You can even get safety using logic without the compiler. I think resource cleanup responsibility tracking as a static analysis tool is likely to happen with some of these languages. I think zig is a good candidate, once they lock down the intermediate representation.
It's already the case that people are using "logic add-ons" for additional rust static analysis, so one wonders exactly why is it generally speaking that borrow checking itself must occur at the compilation step.
Trivially, one could create an annotation layer on top of zig or c that exactly replicates the rust syntax and performance borrow checking in the same way. It wouldn't be exactly the same because there isn't RAII but you can make correct inferences about what is happening in the body of the functions.
Many proclaim that compile-time safety using type theory is the only way to create reliable low-level software, but I think it can alternatively be done with good data structure design and various compiler tooling that instead catch these errors at runtime (generational indices/references, Address Sanitizer, and recently Zig's safety mode). We need to explore multiple directions to really solve the memory safety problem, and I don't think Rust is the only way (although it is a viable way, proven by some recent successful applications).