Rust won Stack Overflow's most-loved language seven years running, from 2016 through 2022. Then the survey renamed the category to "most admired" and Rust won that too, in 2023 and 2024, at 83%.
Same surveys, usage numbers: about 9% in 2022, roughly 11% in 2023, around 8% in 2024. JavaScript sits near 63%.
So the most admired language in the industry is used by fewer than one in ten developers, and the gap has been stable for the better part of a decade. That's not a lag. Lags close. This one hasn't.
The gap is real, not a survey artifact
The obvious objection is that Stack Overflow's respondents skew web developer, and Rust's home turf is systems programming. Fair, and it's worth discounting the raw percentage for that. But the pattern shows up everywhere else too.
GitHub's Octoverse has Rust as one of the fastest-growing systems languages, and also not in the top ten by pull request volume. It ranks high on "most adopted," which measures developers picking it up, and low on "most used," which measures what they actually work in. People try Rust. They largely don't end up living there.
The job market says the same thing in dollars. Rust postings run somewhere between a twentieth and a fiftieth of JavaScript and TypeScript volume in the US, call it 1,500 to 3,000 a month against 50,000 to 80,000. Go, the closest comparison, sits around 8,000 to 12,000.
And the roles that do exist pay a 15 to 25% premium, averaging around $150,000 to $170,000. That premium is scarcity pricing, not productivity pricing. There are also very few junior Rust roles, so the population skews toward senior systems engineers who would command high salaries writing anything.
The learning curve is not the reason
"Rust is hard to learn" is the standard explanation, and the best available data doesn't support it.
Google surveyed over a thousand of their engineers who had written Rust, only 13% of whom had prior Rust experience. Two-thirds reported feeling confident contributing to a Rust codebase within two months. Roughly a third hit productivity parity with their previous language in under two months, and more than half by four months. Google's own summary: they saw no data indicating any productivity penalty for Rust relative to the other languages those developers had been using.
Two months. For experienced engineers with decent internal support, that's a normal onboarding cost for any unfamiliar stack.
The same survey did surface real complaints, just not the ones the folklore predicts. Compile times were the number one issue, with only about 40% finding them acceptable. Macros, ownership and borrowing, and async programming rounded out the top challenges. Notably absent from the top of that list: unsafe code and C interop, which is what everyone assumes will be the nightmare.
So the borrow checker is annoying and the compiler is slow, but neither of those explains an 80-point gap between admiration and use.
The reason is that you can't do it halfway
The better explanation is structural, and the migration timelines make the case better than any argument.
Dropbox rewrote their sync engine from Python to Rust. It took about four years. Four years of engineering on the core of a product used by hundreds of millions of people, while maintaining the old system in parallel.
Cloudflare's Pingora replaced NGINX and delivered genuinely spectacular numbers, roughly 70% less CPU and 67% less memory for the same traffic. Before building it, they say they evaluated their options every quarter for several years. The build itself looks like another year or two on top of that.
Discord's read states rewrite took about six months with a small team, and it's the fastest one in the set because it was scoped to a single service rather than a platform.
Figma's version is the most instructive, because they deliberately didn't commit. In 2018 they moved only the performance-critical document serialization path into a Rust child process and kept Node handling network I/O, on the grounds that Rust's async ecosystem wasn't mature enough for the rest. Evan Wallace's framing was that their multiplayer server was a small amount of performance-critical code with minimal dependencies, so rewriting it was a good tradeoff for them. Note the qualifiers. That's a carefully bounded decision, not an endorsement.
The pattern across all four: Rust adoption is a project, not a preference. TypeScript got adopted because you could rename one file and keep going. Rust has no equivalent move. There's no // @ts-nocheck for the borrow checker, no gradual mode where half your service is Rust and half is Python and they share a heap.
You can adopt Rust for a new service. You can adopt it for one hot path with a process boundary and a serialization format between. What you can't do is adopt it Tuesday afternoon and see how it goes.
The cost is not the code
Which reframes the whole "is Rust worth it" question. The compiler is fine. Two months to productivity is fine. The premium salary is annoying but survivable.
What you're actually buying is a multi-year project with parallel system maintenance, a hiring pipeline into a talent pool a fiftieth the size of the one you're currently fishing in, and an ecosystem that will have gaps you personally have to fill. Cloudflare wrote their own HTTP library rather than use hyper, because they needed to handle traffic that doesn't respect the RFCs. That's not a footnote, that's a subproject.
Look at who successfully made these migrations: Cloudflare, Dropbox, AWS, Google, Microsoft, Discord, Figma. Every single one is a company that could afford to assign senior engineers to a multi-year infrastructure project with no shipped features at the end of year one.
There's also a hole in the case study genre worth naming. Public failure stories are basically nonexistent. Nobody blogs "we started a Rust rewrite, burned nine months, and rolled it back." The successes are real and well documented, but they're a survivorship sample drawn entirely from companies with unusual resources.
The gap is a market signal
The 83%-loved, 9%-used split isn't developers being irrational or timid. It's a fairly precise measurement of switching cost.
Developers understand what Rust gives you. Memory safety without a garbage collector, predictable latency, low resource usage, and a compiler that catches an entire category of bugs before they ship. Google's Android data has Rust at roughly a thousandth the memory-safety vulnerability density of their C and C++, alongside 4x lower rollback rates and less time in review. The value is not in dispute.
The 83% is the value. The 9% is the price.
Every year that gap stays open is a year the industry is collectively saying the benefits are obvious and the entry fee is still too high. Which makes the interesting question not "why don't more people use Rust," a question we've now answered several times over, but whether anything can lower the entry fee without lowering the benefits.
Because if the price came down, the demand is clearly already there. It's been sitting at 83% for a decade, waiting.