Disagree. GCed languages prevent the majority of errors the higher complexity of Rust unloads on the programmer to solve by wrestling with its syntax.
So this is only a plus for Rust, if the small performance advantage over, say, Go, actually matters in an application, which is rarely ever the case in most software written.
Rust has been my favorite language by far to refactor in.
Forcing Rust into a domain where a GC'd language is more than enough offers absolutely zero advantages (yes, you'll have no memory safety issues, but neither you would have had you used Python or Java or Go or whatever), and it's the kind of obnoxious overzealousness that I'm denouncing.
If you're using Rust to write web services you're just wasting your time, I agree with that.
But if the alternative would be C or C++, Rust is at least worth consideration. Ironically, those are domains where you'll have to use a lot of unsafe and/or limit yourself to a subset of Rust, but it's still a nice incremental improvement.
There are lots of programs where Rust isn’t necessary, but it still has a bunch nice-to-haves besides memory management.
It is refreshing to see that other people share this point of view. I guess we are not disagreeing after all.
The other value that Rust adds, that you're ignoring, is control over mutable/immutable access. In Rust, to share data between threads of execution, you have to grab a lock or such. In many other languages, like Go, the lock is advisory not mandatory, and nothing prevents two threads from writing to the same struct field concurrently.
I personally think I'd really enjoy a "GC'ed Rust" for many uses. I wish GC was a Rust feature crates could opt in to, and then the embedded & high performance crowd could avoid that like no_std works today.