I remember another study which showed that actually, most computer programmjng languages today are objectively terrible in terms of legibility and usability, the alternative was some idealized language that allowed effective communication to occur.

A safe program is not necessarily one that won't compile, if the lack of functionality incurs some danger on its own.

I suspect that a majority of the peanut gallery is rather lazy, or unwilling, or economically unmotivated to put forth the proper effort (and it is the last category that deserves the harshest punishment, where a wasteful and harmful situation is actively encouraged).

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.

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.