Why I'm Using Rust for All My Code Now

RUST is sooo fast… I’m sold

I finally got my terminal UI app working in RUST and I’m sold… it is sooo fast. Some days I still don’t think I’m smart enough to use it yet and that the compiler personally hates me. The compiler just won’t let me be stupid which is a good thing. I looked at some of the code I created early on with AI and it’s horrifying. I seriously need to go cleanup my public github profile.

OK, so back to RUST. Early in my career I spent a lot of time analyzing memory dumps and cross-referencing C++ source, and the usual suspects were the kinds of bugs that make native software miserable to debug: memory leaks, use-after-free, race conditions, deadlocks, lock contention, and other synchronization failures. I did not write a ton of C++ myself. Most of my coding was in languages with memory management and garbage collection. That removes some categories of memory-lifetime bugs, which is often safer, but it is not always faster, and sometimes the GC introduces behavior or pauses you do not want. I remember having to learn how the .NET memory manager actually worked, what Generation 0, 1, and 2 meant, and why objects kept surviving longer than I expected. So many times I would open a managed memory dump, start tracing allocations, and follow object references trying to figure out what was keeping everything alive. Before long, the debugger had completely taken over my day. That is part of why Rust feels so different to me. It gives you the kind of performance and control that normally comes with native code, but it pushes a huge amount of memory and concurrency correctness up front into the compiler. Instead of discovering bad lifetime decisions or synchronization mistakes later in a dump, Rust forces you to deal with them while you are writing the code.

Additionally, when I count the number of tabs I have open in my browser and see how much memory they are using, it is hard not to pause for a moment. If you really want to scare yourself, open Edge or Chrome Developer Tools and take a look at what is actually happening inside a modern front-end app—layers of frameworks, dependency bundles, background workers, state managers, and a small forest of JavaScript objects all doing their part to render a button and a table.

At some point you start wondering how much of that complexity is actually necessary.

I am getting tired of using tools that feel like an entire browser had to be assembled just to help me click a button and view a table. A Rust CLI or native application can cut through a lot of that overhead. It removes the browser runtime from the equation, avoids much of the front-end dependency sprawl, and gives you far tighter control over performance, memory usage, and behavior.

And after running an Exa search across recent Rust comparisons, security writeups, and engineering articles, I finally understand something I used to observe from the outside:

Rust developers are passionate because the language changes the quality of your thinking.

It is not just fast. It is clarifying.

Rust Makes Me Think Before the Code Exists

There are languages that let you explore ideas quickly and fix the consequences later.

Rust is not one of them.

Rust makes me model the problem more carefully before I write the code, because I know the compiler is going to interrogate every vague assumption I try to sneak past it.

That turns out to be a feature, not a defect.

When I write Rust, I have to decide things earlier:

who owns this data
what can mutate and when
whether an operation can fail
whether this work should be synchronous, asynchronous, or message-based
what invariants the type system should enforce instead of leaving for runtime

That changes the shape of the design.

In Python or TypeScript, I can move fast with a partially formed model in my head. Sometimes that is exactly the right thing to do. But if I am honest, that flexibility also lets me postpone thinking that the system will eventually demand anyway.

Rust simply presents the bill up front.

I would rather pay it there.

What the Exa Search Reinforced

I used Exa to pull together recent articles comparing Rust with C++, Go, Python, JavaScript, and TypeScript, along with security-focused adoption notes. The sources varied in quality, but the stronger ones kept converging on the same themes:

Rust is in the same native-performance class as C and C++ for many workloads.
Rust gives stronger memory-safety and thread-safety guarantees than C++ by default.
Rust gives better runtime predictability than garbage-collected languages like Go, Java, JavaScript, and Python.
Rust shifts work from runtime debugging to compile-time design.
Teams using Rust for critical infrastructure care less about ideology and more about reliability, tail latency, and operational control.

The most credible data point in the Exa results came from Google’s Android security team. In its 2025 writeup on Rust adoption, Google reported that memory safety vulnerabilities fell below 20% of total Android vulnerabilities for the first time, that Rust had roughly 1000x lower memory-safety vulnerability density than Android’s C and C++ code, and that Rust changes showed a 4x lower rollback rate while spending 25% less time in code review.

That is the kind of result that matters to me.

Not because I expect every personal project to look like Android, but because it reinforces the deeper point: the safer path is not always the slower one. Sometimes the stricter language ends up being the faster engineering system once you count debugging, rollbacks, operational incidents, and production weirdness.

Why Rust Feels Better Than Python and TypeScript to Me

I still think Python and TypeScript are incredible languages for prototyping, scripting, glue code, UI work, and shipping ideas quickly.

But both of them let me get away with too much.

Python gives me speed of expression, a massive ecosystem, and almost no resistance at the moment of creation. That is wonderful when I want to test an idea in ten minutes. It is less wonderful when the code grows teeth and starts living longer than intended.

TypeScript improves the situation, especially compared with plain JavaScript, but it still lives on top of a garbage-collected runtime with a very different performance profile from native code. It gives me better structure, but not the same kind of hard guarantees Rust gives me.

Compared with Python and TypeScript, Rust gives me several things I increasingly value more:

much tighter control over allocations and memory behavior
far lower runtime overhead for performance-sensitive work
stronger guarantees around invalid states and failure handling
better confidence that concurrency mistakes are being caught earlier
compiled binaries that are easier to reason about operationally than a large dynamic runtime stack

The tradeoff is obvious: Python and TypeScript are easier to sketch with. Rust is harder to fake with.

That is exactly why I trust it more.

Why Rust Feels Better Than Go for the Kind of Systems I Want to Build

Go is still one of the most pragmatic languages ever made for backend systems. I understand why people love it. Fast compiles, simple deployment, a great standard library, and concurrency primitives that are easy to get productive with.

But Go optimizes for simplicity at the language boundary and pays for some of that simplicity at runtime.

Rust makes the opposite trade.

The Exa results repeatedly surfaced the same Go-versus-Rust distinction: Go is usually easier to get into production, while Rust gives tighter control over memory, latency, and correctness once the system gets demanding.

That matters to me because I care less and less about average throughput in the abstract and more and more about predictable behavior under stress:

stable tail latency
controlled memory growth
explicit ownership
deterministic cleanup
fewer hidden runtime costs

Go’s garbage collector is an excellent engineering trade for a huge number of services. But if I want the runtime to be as transparent as possible, Rust’s no-GC model is more aligned with how I want performance-critical systems to behave.

Put differently: Go helps me move fast by reducing cognitive load. Rust helps me move carefully by refusing vague runtime tradeoffs.

Right now, I want more of the second.

Why Rust Feels Better Than C++

This is the comparison that finally made Rust click for me.

C++ gives extraordinary control, extraordinary performance, and extraordinary freedom.

It also gives you enough rope to weave a parachute or hang your whole service.

The Exa material was consistent on this point: Rust and C++ are in roughly the same performance conversation for many real workloads, but Rust changes the default safety model in a way that is hard to ignore once you have spent time dealing with memory corruption, undefined behavior, or concurrency bugs.

Rust’s ownership and borrowing system does not eliminate every problem. unsafe still exists. Poor design still exists. Bad architecture still exists.

But it does make several expensive classes of mistakes much harder to represent:

use-after-free
double-free
many data races
invalid aliasing patterns
a lot of “this passed tests and still blew up later” memory behavior

That is a huge deal.

I do not need infinite flexibility. I need disciplined flexibility.

Rust feels like a language designed by people who deeply respect performance and deeply distrust avoidable nonsense.

I relate to that.

Why Rust Developers Are So Passionate

I used to interpret Rust enthusiasm as a mix of genuine admiration and a little too much missionary energy.

Now I get it.

The passion is not just about benchmarks. It is not just about syntax. It is not even just about memory safety.

It comes from the feeling that the language is trying to keep the engineer honest.

Once the mental model starts to click, the compiler stops feeling like an obstacle and starts feeling like a brutally competent reviewer who never gets tired, never misses edge cases, and refuses to approve sloppy reasoning.

That creates a very specific emotional arc:

First you feel blocked.
Then you feel corrected.
Then you realize the correction is improving the design.
Then you ship something that feels more solid than what you would have written in a looser language.

That last part is where the passion comes from.

It is not fandom. It is relief.

The language is strict, but the strictness cashes out into confidence.

The Speed Part Is Real

And yes, Rust is also just ridiculously fast.

That matters more than people sometimes admit. There is a category of programmer discourse that treats performance as vanity until the bill arrives in production, at scale, under concurrency, with real latency SLOs and real infrastructure cost.

I am increasingly uninterested in pretending that runtime efficiency is some niche concern.

If I can get:

native-code performance
no garbage collector pauses
strong compile-time guarantees
compact deployment artifacts
explicit control over resource usage

then I would like to have those things.

The Exa results were especially useful here because they framed the benefit correctly. The win is not only raw speed. It is predictability. Rust gives me a better shot at building software that is fast, stays fast, and behaves consistently when the load or complexity goes up.

That is a much more valuable property than a flashy benchmark chart.

I will still use other languages when they are clearly the better fit. Frontend work is still frontend work. Some ecosystems are still too valuable to ignore. Some experiments should absolutely start in a looser language.

But my center of gravity has changed.

And it changed because I finally stopped treating the compiler’s strictness as a tax and started treating it as leverage.

Bottom Line

I am using Rust for all my code now for a very simple reason:

I want a language that forces me to think.

I want a language that does not let me be lazy with state, memory, concurrency, or errors.

I want a language that rewards rigor with speed.

I want a language that makes more of the system explicit before it runs.

And yes, I want the absurd performance too.

After spending time with the language and then validating the bigger picture with an Exa search, I finally understand the emotional core of the Rust community.

They are not passionate because Rust is trendy.

They are passionate because once it clicks, it feels like you have been handed a sharper set of tools and a stricter standard for your own thinking.

That combination is hard to walk away from.