Approximately nobody is using Plan 9 or Itanium. Apart from nerd cred, they don't matter for Rust's future. People can keep using C for the weird DSPs that don

Approximately nobody is using Plan 9 or Itanium. Apart from nerd cred, they don't matter for Rust's future. People can keep using C for the weird DSPs that don't have 8-bit bytes. Besides, there's already a compile-to-C implementation of Rust (mrustc), and a GCC-based implementations in progress (both front-end and back-end). OTOH Rust and its tooling are way better than the C ecosystem in supporting both Windows and Unix flavors in the same codebase, in a practical manner. C prides itself in theoretical support for obsolete and niche platforms, but requires a mess of ifdefs for basic things like opening a file with non-ASCII characters (and when C programs don't work on Windows, this is dismissed as Windows' problem, not C failing to actually have the standardization and portability it claims). For a lot of programs "cargo build" just works out of the box on every Rust-supported platform. That's smoother than battling autotools, or cmake build scripts that can't find packages for inexplicable reasons, and random breakages due to C compilers/OSes having functions defined in slightly different headers, with their own quirks. Rust is really good at abstracting these pains away, so while it can't support Plan 9, it can easily support Windows. Can you imagine opening a TCP socket without needing to know about winsock idiosyncrasies?