Why Rust Is Becoming One of the Most Loved Programming Languages

I look at the Stack Overflow survey streak, what the admiration score actually measures, why practitioners cite correctness over performance, and where Rust is already running in production.

Why Rust Is Becoming One of the Most Loved Programming Languages

Rust is used by 12.6% of developers, according to the Stack Overflow Developer Survey 2024. That puts it behind Go, Kotlin, PHP, C#, C++, Java, TypeScript, Python, JavaScript, and SQL. By usage, it’s not even in the top ten.

And yet, in the same survey, Rust scores 83% in the admired category — the highest of any language — for what the survey describes as the ninth consecutive year. Fewer than 1 in 8 developers use Rust, but the developers who do use it keep wanting to.

That gap is the interesting part. It’s not hype, because the people reporting high admiration are already using it. It’s not novelty, because the streak is now nearly a decade long. Something about the experience of writing Rust makes people want to keep writing it. That’s what I want to explain here.

This post is deliberately different from the Rust for TypeScript Developers series I’ve been writing — that one is a twelve-part how-to track. This is an analysis post: what the survey result actually means, why the underlying reasons hold up under scrutiny, and where the adoption already landed in real production systems.

On this page

What the admiration score actually measures

The Stack Overflow survey asks two questions together: have you used this technology in the past year, and do you want to use it in the next year? The “admired” percentage is the share of current users who answered yes to both. It filters out everyone who has not actually worked with the language. Only the people who survived the learning curve are counting.

Rust sits at 83% admiration in 2024. TypeScript, which I use daily and genuinely like, is at 69.5%. JavaScript is at 62.4%. Go, widely praised for its simplicity, is at 82.2%. Rust is ahead of all of them.

The 12.6% usage number is part of the story, not a counterpoint to it. It means the 83% comes from a smaller, self-selected group — the developers who pushed past the initial friction far enough to use Rust in an actual project. That selection bias is real, but so is what it implies: the language does not just attract enthusiastic starters. It retains experienced users at a rate that few languages match.

Correctness first, performance second

The standard explanation for why people like Rust is performance. No garbage collector, predictable latency, benchmarks that rival C. All of that is accurate. But it is not the primary reason that practitioners are choosing Rust at work.

The 2023 Rust Annual Survey asked organizations that use Rust professionally what drove that decision. The top answer was “the ability to build relatively correct and bug-free software” at 86% of respondents, up 4 percentage points from the previous year. Performance characteristics came second at 83%.

That ordering matters. The people building production systems with Rust — the ones spending engineering hours on adoption, dealing with the borrow checker, training new team members — say correctness is the bigger draw. Performance is a bonus. Correctness is the point.

In the same survey, 79% said Rust helped their company achieve its goals, and 77% said their organization is likely to use Rust again. The number who said Rust was worth the cost of adoption climbed from 60% in 2022 to 64% in 2023.

Memory safety without a garbage collector

Most memory-safe languages reach safety through a runtime garbage collector. Python, JavaScript, TypeScript, and Go all track live objects at runtime and free the memory once nothing references them anymore. This works well for most workloads. The trade-off is GC pauses, higher baseline memory usage, and latency variance — tolerable in a web API, noticeable in a game engine or a network proxy, serious in a kernel driver.

Rust enforces memory safety at compile time through an ownership system. Every value has exactly one owner at any point. When the owner goes out of scope, the value is dropped. The compiler tracks this statically and rejects code where the rules would be broken. No runtime bookkeeping. No pauses.

If you work in TypeScript, the closest analogy to what this feels like is turning on strict mode for the first time. Null checks that passed silently before become compile errors. Rust applies that same idea to memory: things that would cause runtime crashes in C or C++ — use-after-free, double-free, data races across threads — become compile errors in Rust.

Here is a minimal illustration of what ownership looks like in practice:

fn main() {
    let packet = String::from("connection handshake");
    handle(packet);
    // packet is no longer valid here — ownership was moved into handle()
}

fn handle(data: String) {
    println!("processing: {}", data);
    // data is freed when handle() returns — no GC needed, no leak possible
}

The function handle takes ownership of data. After that call, the original binding packet is invalid. If you try to use packet again, the compiler rejects it. This is not a runtime check. The program does not compile.

That compile-time guarantee is what the 86% correctness number reflects. An entire class of bugs — the bugs that make up the majority of the most severe security vulnerabilities in production software — structurally cannot survive the build.

The tooling that makes it stick

A language design that is clever on paper does not make developers want to keep using a language. The tooling does.

Cargo, Rust’s build tool and package manager, has an 83% admiration score of its own in the 2024 Stack Overflow embedded technologies section — a strikingly high score for build tooling, which developers usually tolerate rather than appreciate. Cargo handles dependencies, building, testing, linting, documentation generation, and publishing from one consistent interface. There is no separate toolchain to wire together for different stages of a project.

The Rust compiler’s error messages are notably better than most. When you break the borrow checker, the error does not just say something failed — it usually says what rule was violated, which line introduced the conflict, and what a valid alternative looks like. Developers who have spent time debugging cryptic C++ template errors or GC-related performance regressions tend to notice this.

For TypeScript developers specifically: rust-analyzer, the language server, works well in VS Code and Zed. The feedback loop during development is tight. The experience is not fighting the compiler — it is closer to a very strict pair programmer who will not let you write code with a specific category of flaw.

Check this before moving on

  • You can distinguish the admiration score from the usage percentage and explain what each measures
  • You understand that Rust’s ownership system enforces memory safety at compile time rather than at runtime
  • You know that practitioners report correctness, not performance, as the primary reason for choosing Rust at work

Where it is already running in production

Survey results describe preferences. Production deployments describe decisions. Rust has been making real decisions.

Linux kernel: In December 2022, Rust became an official supported language in the Linux kernel with the 6.1 release. The Linux kernel is one of the most conservative software projects in existence. It runs on billions of devices. Adding a second language to it — the first change to that policy in roughly three decades — is a significant signal. The rationale is exactly the one the survey reflects: memory safety in driver code without the overhead of a garbage collector.

Android: With the Android 13 release, approximately 21% of all new native code (the combined C, C++, and Rust total) was written in Rust. The Android Open Source Project had accumulated roughly 1.5 million lines of Rust code across components including the new Keystore layer, the Ultra-wideband stack, and the DNS-over-HTTP/3 implementation. The December 2022 Google Security Blog report on this migration included a specific data point worth quoting directly: “To date, there have been zero memory safety vulnerabilities discovered in Android’s Rust code.” Memory safety vulnerabilities had previously accounted for more than 65% of Android’s most severe security bugs. Their decline tracks closely with the shift toward memory-safe languages.

Windows: The Microsoft Security Response Center has noted for years that the majority of the CVEs it addresses are memory safety vulnerabilities — the same class that Rust eliminates at compile time. Microsoft has been introducing Rust into Windows components, starting with areas where memory safety issues have historically been the most costly to patch.

The pattern across all three: the organizations with the most at stake in security and reliability, dealing with software that runs at the lowest levels of the stack, are the ones that moved first. That is consistent with what the 2023 Rust Annual Survey respondents said they valued: correctness before performance.

What this means if you work in TypeScript

I want to be precise about the scope here. Rust is not going to replace TypeScript for web APIs. The admiration survey does not mean Rust is the right tool for your next project. The 12.6% usage number is the real current state of adoption.

A few things are true for TypeScript developers specifically.

If you’ve worked through the TypeScript strict mode journey — understanding why null checks matter, why you should not cast types away without understanding the implications — you have already started building the mental model that Rust extends. TypeScript teaches you to think of types as constraints on what a value can be. Rust asks you to think of ownership as a constraint on who is responsible for a value’s lifetime. The jump is significant, but not from a standing start.

If you’ve worked through my post on Rust ownership and borrowing, you’ll recognise how the compile-time enforcement described in this post actually works in practice. The TypeScript for JavaScript Developers post covers a similar mental shift — from a looser model to a stricter one — if you are still at that earlier stage.

The more immediate question is what Rust’s production adoption means for your existing work. Tools you already use are being rewritten in Rust for performance and reliability reasons. The influence is showing up in the layer below your TypeScript, whether or not you ever write a line of Rust yourself.

If you are curious about learning it, the honest summary is this: the learning curve is real — the 2023 Rust Annual Survey found that 31% of non-users cited perceived difficulty as a barrier. The compiler’s demands are strict by design. But the developers who work through it are the same ones producing the 83% admiration score year after year. The streak did not happen because Rust is fashionable. It happened because the experience of writing it is genuinely different.

The Rust for TypeScript Developers series starts from the ownership model and works through the full language over twelve posts, using TypeScript comparisons throughout. It’s there when you’re ready.

Sources