Ask two experienced Rust developers whether learning Rust was worth the effort and you can get completely opposite answers. One may tell you it did nothing for their career; another may call it one of the best technical decisions they made. Both can be right.
That contradiction is where the question "is Rust worth learning" really sits, and it's why a blanket yes is useless to you. Rust is a compiled language whose safe subset enforces memory-safety rules at compile time, without requiring a garbage collector at runtime.
So I'll commit to an answer, name the condition it hangs on, and show you what the condition costs.
The Short Version
Rust is worth learning if you're building something long-lived where the compiler catching a class of bug is worth paying for. It's wrong if you need to ship a CRUD app this month, are learning to program, or are counting job postings. 4 out of 5, docked for what it costs before it pays.
- What you're buying: in safe Rust, ownership and borrowing rules turn use-after-free, double-free, invalid-reference, and data-race bugs into compile-time errors instead of production incidents. That's the whole pitch, and it's a good one.
- What you're paying: the compiler makes you write down memory decisions your current language makes silently, and early on that feels like the tool being difficult.
- The durability question is settled. Kernel maintainers concluded the Rust experiment at the December 2025 Maintainers Summit, and the "experimental" label came off in Linux 7.0.
- The fashion question is not settled, and it's a different question. Rust sits at #10 in TIOBE's September 2026 index, up from #18 a year earlier.
- My test Rust service needed far more memory to compile than to run: it peaked near 1 GB while building and idled at about 3.5 MB running.
- Right for you if you already ship in another language and are building something where a memory bug would be expensive, or you work near systems software. Wrong for you if you're on a deadline, starting from zero, or shopping for the language with the most openings.
How this review was made: the build and runtime numbers here are mine. I installed Rust 1.98.1, wrote a small Axum web service, and measured what it took to compile and what it took to run. That ran in a sandboxed container, not on dedicated hardware, and it's one project, so treat the figures as a data point and not a law. Everything else comes from primary or authoritative sources: the kernel patch and LWN's reporting on it, Google's Android security posts, TIOBE's own index (with April's commentary via Slashdot's record of it), Phoronix on the Linux 7.0 merge window, the Linux kernel CVE records for the Binder vulnerability, Canonical's own statement, and the 2025 Stack Overflow survey. I read the kernel patch. I did not audit kernel Rust code. And I haven't been writing Rust for years, so where this review judges the language itself, it's reading practitioners who have, and naming them.
What the Compiler Buys You
Hand two threads a mutable reference to the same vector in Rust and the code does not compile. Not a warning. Not a lint you can suppress on a deadline. It does not build. That refusal is what you're buying in safe Rust: use-after-free, double-free, invalid-reference, and data-race bugs are pushed into compile errors instead of production incidents. Rust's escape hatch (unsafe) can bypass some of those guarantees, so this isn't an absolute promise about every Rust codebase.
Ownership means every value has exactly one owner responsible for releasing it. Borrowing means you can lend out references, but the compiler tracks their lifetimes and won't let one outlive what it points at, or let a mutable borrow coexist with any other. In safe Rust, use-after-free, double-free, invalid-reference, and data-race bugs are caught by the ownership and type system before the program runs.
There's no garbage collector, which is the other half of the deal. Because ownership already says who frees what and when, nothing needs to trace your heap at runtime. You ship a binary with no collector in it, and you don't get pause times you have to tune around.
The price shows up in the same place as the guarantee. Every memory decision your current language makes quietly on your behalf is one Rust asks you to write down: who owns this, how long that reference lives, whether anything else can see it, and whether it crosses a thread boundary. The compiler isn't being difficult. It's refusing to guess.
So: this is the reason anyone pays what Rust asks, and I think it holds up. If the class of bug it eliminates isn't a class you're worried about, the rest of this review probably doesn't change your mind.
Is Rust Still Experimental, or Is It Production Infrastructure Now?
It stopped being experimental in December 2025, and the people who ended it were the kernel maintainers themselves. At the 2025 Maintainers Summit they concluded that Rust had carried its own weight in the kernel, technically and socially. LWN's Jonathan Corbet reported the consensus on December 10, 2025: Rust in the kernel is no longer experimental.
Rust went into mainline Linux at v6.1 in 2022 specifically to run that experiment. Miguel Ojeda's patch removing the label followed the Summit by three days, and it went in for the Linux 7.0 merge window.
"But the experiment is done, i.e. Rust is here to stay."
Miguel Ojeda, "rust: conclude the Rust experiment," LKML, December 13, 2025
Separately, and earlier: Google's Rust rewrite of Android's Binder driver, the IPC layer Android's processes talk through (constantly), landed in Linux 6.18, which released on November 30, 2025. Keep that milestone apart from the Summit consensus. It's the one where a company bet a shipping product on kernel Rust, not a maintainer group blessing the idea. Kernel Rust has since produced its first CVE: CVE-2025-68260, a race condition in that same Binder driver that Greg Kroah-Hartman announced on December 16, 2025, introduced in 6.18 and fixed in 6.18.1. The initial reports focused on crashes, but the Linux kernel CVE team's later scoring rates CVE-2025-68260 at 7.8 (High) and describes a local privilege-escalation path through kernel memory corruption. The same driver (rust_binder) has also accumulated additional CVEs since.
Android is where the evidence gets numerical. Google's security blog stated in December 2022 that there had been zero memory-safety vulnerabilities discovered in Android's Rust code, against roughly 1.5 million lines of Rust in AOSP and about 21% of all new native code in Android 13. That's a 2022 statement with a 2022 scope. Google's later posts give the longer trend: memory-safety issues accounted for 76% of Android vulnerabilities in 2019 and 24% in 2024, with the raw count falling from more than 220 to a projected 36. Those figures only mean something against the baseline they replaced, which is C and C++ written by very good engineers with very good tooling.
Two smaller signals point the same way. The Apple AGX GPU driver in Asahi Linux is Rust, written by the Asahi Linux project as a reverse-engineering effort rather than by Apple. Canonical's rust-coreutils update says Ubuntu 26.04 LTS ships rust-coreutils 0.8.0 for most utilities. Three stay on GNU coreutils (cp, mv, rm) because eight TOCTOU issues were still open on April 22, 2026; Canonical is targeting 26.10 for the remaining utilities.
This is the axis I'd score highest, and the reason is the kind of commitment involved. Kernel maintainers don't un-conclude experiments, Google doesn't unwind a rewrite that size, and Canonical doesn't put a rewritten coreutils in an LTS to see how it goes. Whatever happens to Rust's popularity, somebody has to maintain that code for years.
Is Rust Dead, or Just Leveling Off?
No. Rust matched its best-ever TIOBE position, #13, in January 2026. Three months later it had dropped back to #16, and TIOBE's CEO Paul Jansen wrote in April 2026, in commentary Slashdot quoted at the time, that Rust's growth in popularity "seems to be leveling off" and that a top-10 position "now appears more distant than before."
He was describing Rust reaching its highest position ever on his own index, a spot it had first held in July 2024, and then giving it back.
TIOBE's September 2026 index puts Rust at #10, up from #18 a year earlier, and past the #13 TIOBE called its highest position ever in January.
My read: the plateau was real. It was an air pocket, not a ceiling. That beats either camp's version, because "Rust stalled" is now wrong and "Rust only goes up" was never true.
The caveat cuts both ways, and Slashdot's writeup raised it at the time: could the rankings just be fluctuating with month-to-month noise in search-engine results, which is what the index counts. If a three-position drop in a quarter was thin evidence that Rust was slowing, a six-position climb is thin evidence that it's winning. Use it as weather, not climate.
The stronger signal on sentiment is the Stack Overflow survey, where Rust is yet again the most admired programming language in 2025 at 72%: people who used it in the past year and want to keep using it. That's continued-use intent, not adoption, and it's a more useful signal here than raw popularity if you're deciding whether you'll enjoy sticking with the language.
Momentum is ambiguous, and I weight it below the durability above, because you're not investing in a ranking.
What Learning Rust Costs You
The cost lands early and all at once. Code that Python or Java or C# would happily run gets rejected, repeatedly, for reasons that feel arbitrary until the ownership model clicks, and there's no way to defer that. You can't ship your way past the borrow checker the way you can ship your way past not fully understanding your ORM.
Here's the part that surprised me, and it runs backwards from what you'd expect. In the r/rust "Struggling to learn Rust" thread, the reply that got the most traction reframes the problem as unfamiliarity, not difficulty, and the thread points at experienced developers arriving from garbage-collected languages as the ones having the harder time. u/Voxelman puts it plainly: "Rust is not difficult. It is different." In the same thread they describe their own route in: C64 Basic, then a range of imperative languages, and a first contact with Rust that "was anything but WOW" because shedding the old habits took a while.
That's the shape of the bill. If you've been writing Python for eight years, you're not learning a set of rules, you're giving up a set of assumptions about who cleans up after you. Somebody who knows less has less to unlearn.
One more pattern shows up repeatedly in that thread, and it turns a sequencing mistake into a confidence problem: people get stuck not on Rust but on picking a web framework, trying to learn the language through Axum or Actix before ownership has landed. As u/jmartin2683 put it, that's "like trying to learn ruby by learning rails."
I read most warnings about the cost as pointing at the wrong thing. Budget sustained practice, not a weekend, and don't read early frustration as a verdict on your ability.
Rust Needs a Bigger Machine to Build Than to Run
Here's the finding I didn't expect: building this Rust project took orders of magnitude more memory than running it. I built a small Axum service (Tokio with the full feature set, serde, serde_json, tower, one JSON route, about 60 crates in the dependency tree) on rustc and cargo 1.98.1, with strip = true in the release profile, then built it from clean twice:
# constrained: one compile job at a time
cargo build --release --jobs 1
# unconstrained: default parallelism, 4 vCPUs available
cargo build --releaseCapped at one compile job (--jobs 1), peak memory across cargo, rustc, and the linker came in between 464 MB and 527 MB depending on which of my two measurement methods you take (I measured it two ways because the first number looked too clean), and it took 113 seconds. With default parallelism on four vCPUs, peak memory roughly doubled to about 1 GB and the build finished in about 35 seconds. Parallelism is the variable there, not the project. More jobs means more rustc processes resident at once, which is why compilers are one of the few workloads that will happily take every core you give them for minutes at a stretch.
The finished program is 1.3 MB stripped, and it idles at roughly 3.3 to 3.6 MB of memory in use.
At default parallelism that's two to three hundred times more memory to compile than to run; capped to one job it's still well over a hundred. Size a server around what your Rust service needs in production and you can end up with a box that can't build it, and the failure mode isn't a clean error: it's the out-of-memory killer taking rustc out mid-build, or a compiler thrashing swap for twenty minutes. Two answers work. Build somewhere with headroom and ship the binary, the same pattern as keeping a separate build box for heavy Docker work. Or build on the box and give it room: for a service this shape, a couple of gigabytes of RAM and two vCPUs is comfortable. When it isn't, the escape hatch is --jobs 1 (yes, it's slower; that's the trade).
If the machine you work on doesn't have that headroom, our self-managed Linux VPS gives you root access on hourly or monthly billing and somewhere to put the build and hand back when you're done, though it's still a server you operate rather than one that operates itself.
One project, one shape, one machine. The machine was a shared sandboxed container, not a dedicated server, with roughly 2 GB of memory available, so the unconstrained peak was running nearer its ceiling than it would on a bigger box. These are not a universal constant: if your dependency tree is four times the size or your release profile turns on link-time optimization, expect different numbers. Larger dependency trees, link-time optimization, and generic-heavy code can push build memory higher, so don't treat my measurements as a universal ceiling.
I'd file this under how you work, not whether you learn the language. Know about it before you hit it.
Who Should Learn Rust
Three situations where I'd tell you to spend the time: long-lived software where a memory bug is expensive, work that sits close to the operating system, and wanting what fighting the compiler does to how you think about memory. Each has a reason that time pays back.
You already ship in another language and you're building something long-lived where a memory bug would be expensive. A service that has to stay up. A library other teams depend on. Anything where a use-after-free means an incident review, not a stack trace in your terminal. This is the case the whole guarantee was built for, and what you pay up front amortizes over the lifetime of the thing you're building.
You work near or inside systems software. Drivers, device work, base-system utilities, embedded, anything that sits under an operating system instead of on top of one. The industry has committed here in a way it hasn't elsewhere, and the memory-safety evidence is strongest here.
You want the side effect. Two commenters in that r/rust thread disagree completely about Rust's career value and land in the same place here. u/tyler_church, who says it had zero career impact, still allows it "maybe subtle influences on how I write other programs in other languages." u/SirKastic23, two years into being paid to write Rust, says it broadened their coding skills in ways they never expected. Two people, not a study, but it's the payoff that survives you never writing Rust professionally: a change in how you think, not a line on a résumé.
Who Shouldn't Learn Rust
Three situations where that time is better spent elsewhere: you have a deadline this month, you're learning to program at all, or you're picking a language by how many job postings mention it. The third is the one people ask about most.
You have a deadline this month on a CRUD app or a prototype. Rust arrives on exactly the wrong schedule for work that has to exist by Friday. Go is the obvious thing to reach for instead if you want a compiled language with fast builds and garbage-collected memory management, and you don't need Rust's ownership-based guarantees.
You're learning to program at all. This one genuinely splits people who write Rust for a living, and the disagreement in the r/rust threads runs in both directions, so my position is that handing a beginner a coin flip is bad advice regardless of which way the coin lands. Learn how a machine works somewhere more forgiving first, then come back and let the compiler tighten it.
You're picking a language by how many job postings mention it. I won't give you a number here, because I couldn't find a salary or opening figure for Rust that traces to a source I'd defend. What u/crusoe describes in that r/rust thread is a market with fewer, more specialized positions. That's one commenter in one thread, not labor-market data, so I wouldn't turn it into a claim that Rust jobs are broadly scarce. If job volume is your deciding factor, check current postings in your target market before choosing the language.
Frequently Asked Questions
Is Rust Free?
Yes. The language and its official projects are generally dual-licensed under the MIT license and Apache License 2.0, and the toolchain installs free through rustup. There is no paid tier and no commercial license to buy.
How Long Does It Take to Learn Rust?
If you already program, the syntax is usually the easy part. Ownership and borrowing take longer because they change how you think about memory, and lifetimes and async Rust add another layer later. I couldn't find a defensible universal timeline, so I wouldn't put a number on it.
Is Rust a Good First Programming Language?
My answer is no, but you should know the question is contested among experienced practitioners. In the r/rust "Struggling to learn Rust" thread, u/cassepipe says flatly that Rust "is not a good first language" after bouncing off it and returning via C and C++, while u/Voxelman argues the opposite: imperative languages are a bad place to start because they teach habits you then have to shed. The same disagreement runs for four pages on Rust's own user forum. There is no settled community answer to report.
Is Rust Replacing C++?
No. Rust is being added alongside C and C++ and chosen for specific new components, which is a different thing. In the Linux kernel, Rust is being added alongside the existing C codebase rather than replacing it wholesale. In Android, Google's stated approach has been to write new code in memory-safe languages rather than convert existing C and C++. Expect coexistence for a long time.
Is Rust Faster Than Go?
I didn't benchmark this, so I won't claim that one is categorically faster. Rust gives you finer control over allocation and doesn't require a garbage collector; Go uses a garbage-collected runtime and trades some low-level control for simpler development. Which one is faster depends on the workload, implementation, and bottleneck, so use benchmarks that resemble your own application.
Discussion
Comments
Sign in to join the discussion.