The current advice, delivered with confidence in every second thread: point your agent at the codebase and have it rewrite the slow parts in Rust. Sean Goedecke's essay on why that usually won't work is the best short argument I've read against the fashion, and it's worth engaging because the fashion is expensive.
His claim is narrow and mostly correct: for most programs, language speed is not the bottleneck. Rewriting a Python service in C can only speed up the CPU-bound fraction, and in a typical CRUD app the database queries, API calls and disk waits don't care what language is waiting on them. That's Amdahl's law wearing a hoodie.
The two arguments inside the argument
There are actually two claims in the piece, and they have different strengths.
The first is empirical: most real programs are I/O-bound. For a web app, he estimates something like half a request's time in database work, which caps a rewrite at roughly a 2x win and delivers closer to 1.5x in practice. That matches the flamegraphs most backend engineers have seen: a request making forty small queries is not slow because Ruby is slow.
The second is strategic: even where CPU does dominate, the fast path is usually a redesign — cache the slow call, move work out of the request cycle, parallelise, fix the N+1, skip work you didn't need. His list is unglamorous and correct. None of it requires a new language.
The strategic claim is stronger than the empirical one, and it's the one that survives the counterexamples.
Where the essay is weaker
The "most software is CRUD" estimate is the soft spot. He puts non-CRUD, genuinely CPU-bound software at around five percent of programs, and admits the number is a guess. It is — but it's also a guess shaped by his sample, which is Rails monoliths. Add embedded systems, games, browsers, codecs, databases, compilers and numerical work and the denominator looks different. His defence is that those categories dominate discussion out of proportion to their number, which is probably true, and that the median working engineer is not writing a layout engine, which is definitely true.
The other pushback is one he half-concedes in his edit: ecosystems shape design. A language whose idioms make the fast design natural will produce faster software, not because the compiler is better but because the default is better. He files that under design, and he's right to, but it means "language choice" and "design" aren't as separable as the headline suggests.
The best counterexample is his own
The most interesting anecdote in the essay is Bryan Cantrill's 2018 experiment: a careful C program rewritten naively in Rust came out about 30% faster, because Rust's default map is a B-tree rather than a binary search tree, and the B-tree is friendlier to the cache. That's a language choice producing a design difference producing a speedup — all three at once, in a workload that was genuinely CPU-bound.
It also shows why "rewrite it in Rust" sometimes works for reasons nobody predicted. Not because Rust is faster on paper, but because the rewrite forces different data structures. That's an argument for rewriting as a design intervention, not as a compilation trick.
What AI actually changes
Goedecke is careful here, and this is where the essay is most useful: making rewrites cheap doesn't make them the right move. If anything, cheap rewrites raise the value of cheap measurement. The scarce step is knowing where the time goes and what work could be eliminated. An agent that profiles, reads the flamegraph, and proposes "stop fetching this per-row" is doing something a language migration never does.
The tiktoken-in-assembly footnote is a nice illustration of the trap. The rewrite claims 4–23x over the original; Goedecke measured about 5x on his laptop, then noted the win may come from eliminating a regex dependency rather than from assembly. Even the triumphant example is partly a redesign in disguise.
The part worth copying
The essay ends with an edit linking to critical comments on Lobsters and answering them. That's rare, and it's the reason I trust the argument more than the average performance post: the author published the objections next to his claims and said where he might be wrong.
That habit is also the correct response to the current enthusiasm. The claim isn't "never rewrite." It's "measure first, redesign second, rewrite the hot loop third" — and the third step is far rarer than the current discourse implies.
Source: Software is slow because of bad design, not slow languages — Sean Goedecke.