why I reach for Rust

Rust is the language I reach for when the cost of getting it wrong later is higher than the cost of going slower now. That is not every project. It is a specific shape of project. This post is about how I decide.

01 when Rust earns its keep

Three conditions push me toward Rust, roughly in order of weight.

First, the service is going to run hot — throughput-sensitive, latency-sensitive, or both — and the cost of wasted cycles shows up on someone's bill. orca is the clearest example: an agent orchestration core where every tool call is a model call, and every wasted roundtrip is real money. Rust gave me a predictable tail latency without a GC pause landing in the middle of a patient-facing flow.

Second, the code is a library that someone else is going to depend on. omniparse ships as a crate; it has 140k+ downloads and no runtime dependencies on purpose. If I had written it in a language that carries a heavy runtime, I would be shipping that runtime into every downstream project. Rust lets me publish something small, honest about its behavior, and cheap for consumers to vendor.

Third, the code is going to outlive me — or at least outlive my attention. The borrow checker is an argument I lose now so that future-me does not have to debug a data race at 2am. I have shipped enough production Go to know that "it compiles" and "it is correct under concurrency" are not the same claim. Rust closes part of that gap at build time.

02 when it doesn't

Rust is the wrong choice for most web applications, full stop. If you are writing a CRUD service that needs to ship by Friday and the bottleneck is going to be Postgres anyway, Go or TypeScript will get you there faster and the operational characteristics will be indistinguishable in production. I have written those services in Go for years. I will keep writing them in Go.

Rust is also the wrong choice when the team reading the code does not already know Rust. The language is not hard to read; it is hard to change. Handing a large Rust codebase to a team that has been writing Python for a decade is how you get a codebase that nobody touches.

03 the real cost is the borrow checker

People complain about the borrow checker as if it is a bug. It is the feature you paid for. The cost is real — you spend time restructuring code to match an ownership model that most languages do not force you to think about — but the trade is that the class of bugs the borrow checker rules out does not come back to bite you in production.

The hidden cost is something else: the borrow checker makes it expensive to prototype. If I do not yet know what the data model looks like, I will not discover it any faster in Rust. I will write a half-baked design, fight the compiler for a week, and end up with a half-baked design that compiles. In that phase Go or TypeScript lets me move faster and throw things away cheaply.

My rough rule: if I can draw the architecture on a whiteboard and it has not changed in three conversations, it is safe to start in Rust. If it is still moving, I prototype in Go first.

04 savings that show up on the bill

The argument I make to clients is not about speed. It is about the bill at the end of the month.

A Rust service running on Cloud Run at 256 MiB typically handles more throughput than a Go equivalent at 512 MiB.¹

That is a 2x compute cost difference for the same workload, and it compounds across every instance, every environment, every region you replicate into. Over a year, for a service that does real traffic, it is the difference between a line item the CFO notices and one that they do not.

The same math applies to agent pipelines. Every millisecond you trim off the control loop is a millisecond the model is not billing you for. code-review-rs compresses a 2k-line diff from ~80k tokens to ~12k before it hits Vertex. The compressor is a pure-Rust crate with no dependencies; running it is close to free. The tokens it saves are not free.

05 the case I keep making

I do not advocate for Rust because it is better. I advocate for it in the specific cases where the economics line up: long-lived services, shared libraries, throughput-sensitive cores. Anywhere else, reaching for Rust is a tax on the team for the sake of aesthetics.

The question I ask before starting a new service in Rust is: will this code still be running in three years, and will somebody still be paying for it to run? If the answer is yes, the borrow checker is cheap. If the answer is no, it is not.