I do, but with some caveats. Rust is pretty great at spitting out JSON, so I think it fits in best as either the backend for an SPA, "middle end" style services, and/or background jobs that need to do intense processing.
One area that's under-appreciated about Rust in the web space is its low memory footprint: crates.io is written in Rust, and uses about 30MB of RAM, resident, all the time. Lower memory usage means saving $$$ on servers. At least one production user has reported being very happy with this.
Second, npm has stated that they enjoy Rust for their middle end stuff because it's "operationally boring". The Rust service (and soon to be services) is never what triggers pager duty. It just does its job.
We already have decent languages for the backend - if you like types, there are various languages on the JVM, and if you don't, there's Go. They use a lot more memory than Rust, but not a deal-breaking amount for most people, and they go about as fast. They're as or more productive, and likely to stay that way, because of garbage collection.
What we don't have is a decent language for desktop applications, native mobile apps, operating systems, high-throughput low-profile infrastructure, embedded systems, and maximum-performance work. We have C/C++. My life, as a user and a programmer, would be improved much more by Rust levelling up and taking over that space than by getting into a HTTP-pissing match with Kotlin and Go.
Although HTTP does matter outside web development as well. For example, we need a good gRPC library for Rust.