Rust's been the 'most loved programming language' in Stack Overflow surveys since 2016. But 2021 was different. It moved from hobbyist enthusiasm to something production teams at serious companies actually built systems with.
The memory safety argument
Rust's central promise is memory safety without garbage collection. The ownership and borrow checker system enforces at compile time that: only one mutable reference exists at a time, no references outlive the data they point to, and data race conditions are prevented. The class of bugs that cause most security vulnerabilities in C/C++, buffer overflows, use-after-free, null pointer dereferences, are compile errors in Rust.
Production adoption signals
Microsoft began replacing C/C++ code in Windows components with Rust for memory safety. The Android Open Source Project adopted Rust for new OS-level code. AWS uses Rust in Firecracker (the microVM that powers Lambda and Fargate) and in the Bottlerocket OS. The Linux kernel accepted Rust as a second implementation language in 2022. These are not hobbyist adoptions, they are deliberate choices by organisations with strong C/C++ expertise who decided the safety benefits justified the migration cost.
The learning curve reality
Rust's ownership model is genuinely difficult to learn for developers coming from garbage-collected languages. The borrow checker rejects code that would be valid in most other languages. The learning period before productivity is measured in months for most developers. The payoff: once you understand the ownership model, you write concurrent and systems code with a level of confidence that is not possible in C/C++.
Where Rust makes sense
Rust's optimal use cases: systems programming where C/C++ were previously the default (kernel modules, device drivers, embedded systems), performance-critical infrastructure (databases, runtimes, networking stacks), and security-sensitive code where memory safety bugs have severe consequences. Using Rust for a CRUD web API is possible (Actix-web is a Rust web framework) but the development overhead rarely justifies it over Go or .NET for typical web workloads.