This is somewhat subjective, but I'd argue you've got it exactly backwards. I already know "more than enough" GCed languages and use them frequently. That nic

This is somewhat subjective, but I'd argue you've got it exactly backwards. I already know "more than enough" GCed languages and use them frequently. That niche is well covered for me - add a GC, and remove the language tools designed to help deal with the lack thereof, and Rust would be just another language for me to ignore. Even within GCed programs, I sometimes need to reach for manual control over memory or other resources, control lifetimes, control ownership, manage shared access, etc. And sometimes those needs are so pervasive that I want or need to effectively avoid using a GC myself - and so reach for a non-GCed, non-JITed, "manual control over everything" language. This I do not have well covered - traditionally my choice has been the undefined behavior infested, data race prone, "didn't even have threads in the standard library until ~2011", source of bugs and misery - C++. Rust's lifetime and ownership semantics are complex, yes. But on the other hand, they can be used as a much more uniform, clean, and flexible version of e.g. https://clang.llvm.org/docs/ThreadSafetyAnalysis.html https://clang.llvm.org/docs/ThreadSafetyAnalysis.html , which is but the tip of the iceberg of static and dynamic analysis, unit and fuzz testing, etc. I've already been applying to my C++ programs, to try and keep the bugs in check. So Rust is simpler than what I've been doing in practice.