No, it's not. None of the core data structures (String, Vec, HashMap, BTreeMap, VecDeque), for example, use it.
Rust is not a garbage collected language in any meaningful sense of the word. Its runtime is approximately the same size as C's, and the vast majority of all memory management in the Rust ecosystem is done with traditional malloc/free calls. The only difference between Rust and C at this level is that Rust inserts those calls for you automatically. In exchange, the space of programs accepted by the Rust compiler is smaller than what is accepted by a C compiler.
> At the moment it is a garbage-collected language but IIRC they are trying to move away from that as a requirement.
No, we're not. Because no such requirement exists and the vast majority of Rust code doesn't use reference counting at all. If anything, there are some folks that have looked into adding tracing garbage collection to Rust as a library.
The space of safe programs accepted by Rust is indeed smaller, but you can use the `unsafe` keyword if that is an issue. There are even automated transpilers from C to `unsafe` Rust.
https://words.steveklabnik.com/borrow-checking-escape-analys...
Edit: I see your other comment about the use of Arc and Rc in the stdlib, that is a good point. However, how much does that actually matter? I'm genuinely curious, my guess is that it is not significant, but I'm not well informed. For example, would that affect embedded use cases?
Rust is built on LLVM, much like Clang. C integration is relatively easy. I think this is more viable than Go. Unfortunately, Rust is only portable to platforms LLVM supports. While that covers the majority of commonly used hardware today, it is not comprehensive. Also, Rust compile times are pretty bad, especially for optimized builds.
At the end of the day the author gets to write code in a language of their choice to scratch their own itch. End users don't care at all what language a web framework is written in.