There's a few issues from our perspective: * Old platforms which don't have LLVM can't yet have Rust either, as rustc is based on LLVM. These need gccrs to be unblocked. I can understand not caring too much about these, though it is unfortunate, because I think if git hadn't supported many platforms to begin with, I doubt it'd have the adoption it does today. (There is another effort which seeks to take rustc and bolt on libgccjit as a replacement backend, but that isn't feasible for use yet either.) * New platforms where rustc or various Rust crates don't support it and we have to go around patching them. The crate model makes this much harder. Not having git available when doing such porting if doing it natively is going to suck. It also means even more software needs Rust ported first. * Platforms which aren't ancient, just not "the default", which tend not to work well with Rust. For example, rustc assumes that all musl configurations will be statically linked, which isn't the case. Working around this is a hassle. * rustc doesn't have LTS releases or the like. The only supported release is the latest one. Upgrading to the latest release often means we have to deal with new portability problems but we can't not upgrade because: a) some software will start to require bleeding-edge Rust immediately, and b) it means we're missing out on bug fixes (miscompilations are serious) * Crate creep Rust projects tend to end up having a huge list of crates that they pull-in which makes us worried about something nasty creeping in, but there's also popular crates with serious portability problems like the 'ring' crate for TLS. git is a fundamental piece of system software and making it harder to build it or use it is a real worry for us.
