Confession: I’ve started this post three times over two years and thrown it away every time, because every version turned into a benchmark table and benchmark tables are the least useful part of this question.<\/p>\n
Here’s what actually happens. Someone asks “Rust or Go?” What they mean is “I have a thing to build and about six weeks, which one won’t ruin my life.” Nobody is choosing a language for the microsecond difference on a JSON parsing benchmark. They’re choosing what their team will be typing at 11pm during an incident.<\/p>\n
I write both. I ship Go for most services and Rust for a smaller set of things, and after a few years of that the decision has stopped feeling difficult. So let me tell you where the line actually falls for me, and where I got it wrong first.<\/p>\n
Rust is faster than Go for CPU-bound work. That’s true, it’s consistent, and it mostly doesn’t matter for the thing you’re building.<\/p>\n
The reason is the garbage collector. Go has one, and it’s a good one: the Go team’s GC design<\/a> targets sub-millisecond pause times, and in normal service workloads you will not notice it. Rust has no GC, so it has no pauses at all, and it has no runtime allocating things behind your back.<\/p>\n Where that gap shows up in practice:<\/p>\n Where it doesn’t show up: literally any service where the request spends 40ms waiting on Postgres. Your database is the bottleneck. Rewriting the 2ms of application time into 0.4ms is not a project, it’s a hobby.<\/p>\n I say this as someone who once rewrote a Go ingestion worker in Rust to fix a latency problem that turned out to be a missing index.<\/p>\n The case for Rust isn’t speed. It’s that the compiler refuses to let a whole category of bug exist.<\/p>\n The borrow checker means no data races in safe code. Not “fewer”, not “unlikely”. The compiler will not build a program where two threads can mutate the same value without synchronisation. That guarantee is worth an enormous amount on anything concurrent and stateful, and there is no equivalent in Go.<\/p>\n Go’s story here is different. It gives you cheap goroutines and channels and then trusts you:<\/p>\n That builds. It runs. It gives you a number that’s wrong in a way you’ll notice in about three months. The Rust version doesn’t compile:<\/p>\n You’re forced into an The second thing Rust gives you is error handling that you can’t ignore. A Enums are the underrated part. Modelling state as a Rust enum with data attached, then matching exhaustively, catches design mistakes at compile time that Go’s interface-and-type-switch approach finds at runtime. I built a payment state machine this way and the compiler found four transitions I hadn’t thought about.<\/p>\n Compile times. I’m putting this first because it’s the one people dismiss and then feel every single day.<\/p>\n A Go service builds in a couple of seconds. A Rust service with a moderate dependency tree takes a minute or two on a clean build, and incremental builds are decent but not Go-fast. Over a working day of small changes and re-runs, that difference changes how you work. Go keeps you in a tight loop. Rust nudges you toward thinking harder before compiling, which is sometimes good and sometimes just waiting.<\/p>\n Then: onboarding. Go’s spec is small enough that a competent developer from any background is useful in a week. Rust’s ownership model takes longer. Not “hard” longer, but weeks-not-days longer, and the ownership chapter of the Rust book<\/a> is genuinely the wall people hit. If you’re hiring, or if the code needs to be maintainable by whoever comes next, that’s a real cost with a real number attached.<\/p>\n Async is the third one. Go’s concurrency is built into the runtime; you write blocking-looking code and the scheduler deals with it. Rust’s async is a library-level thing built on futures, which means you pick a runtime, you deal with And the standard library. Go’s Go, unless there’s a reason:<\/p>\n Rust, when one of these is true:<\/p>\n The honest summary is that Go is my default and Rust is my choice for specific problems. That’s not a diplomatic non-answer; it’s just what my repo list looks like. Most things are services. Services are IO-bound. Go is very good at IO-bound services.<\/p>\n “Should we rewrite our Go service in Rust?” Almost always no.<\/p>\n The gain is usually latency and memory. The cost is the rewrite plus every bug you reintroduce plus a team that’s slower for a quarter. If your service is IO-bound, you’re spending months to optimise the 5% of the request that isn’t waiting on something else.<\/p>\n What works better: leave the service in Go, find the one hot component, and make that a Rust library. Both languages have decent FFI. You get the win where the win exists and you don’t burn a quarter.<\/p>\n Where I have gone all-Rust from the start, it’s been things like a log-processing pipeline chewing through a large volume of lines, where the per-line cost genuinely dominated. That one was worth it. I laid out the backend shape I ended up with in my axum and sqlx setup<\/a>.<\/p>\n If you’re a Go developer curious about Rust, don’t start with a service. Take one small CLI tool you already have and rewrite it. A hundred lines, no async, no web framework. You’ll meet ownership and If you’re a Rust developer wondering about Go, write a small HTTP service using nothing but the standard library. No framework. It’ll take an hour and it’ll explain the appeal better than any comparison post, including this one.<\/p>\n Either way, pick based on what the thing is, not on which language is winning the argument this month. I’ve built production systems in both and I’ve got no interest in defending either one; if you want to see what that looks like in practice, most of my work<\/a> is somewhere in the middle.<\/p>\n","protected":false},"excerpt":{"rendered":" Rust vs Go, decided by what you are building rather than benchmarks: where the borrow checker pays off, where Go’s compile times win, and when not to rewrite.<\/p>\n","protected":false},"author":2,"featured_media":493,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"rank_math_title":"","rank_math_description":"Rust vs Go, decided by what you are building rather than benchmarks: where the borrow checker pays off, where Go's compile times win, and when not to rewrite.","rank_math_focus_keyword":"rust vs go","rank_math_canonical_url":"","rank_math_robots":"","footnotes":""},"categories":[45,142],"tags":[49,212,46,47,566,64,565],"class_list":["post-494","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-programming","category-rust","tag-backend","tag-concurrency","tag-go","tag-golang","tag-language-comparison","tag-rust","tag-systems-programming-2"],"_links":{"self":[{"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/posts\/494","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/comments?post=494"}],"version-history":[{"count":0,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/posts\/494\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/media\/493"}],"wp:attachment":[{"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/media?parent=494"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/categories?post=494"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/tags?post=494"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}\n
Where Rust actually earns it<\/h2>\n
counter := 0\nfor i := 0; i < 100; i++ {\n go func() {\n counter++ \/\/ data race, compiles fine, runs fine, wrong answer\n }()\n}\n<\/code><\/pre>\ngo run -race<\/code> catches it if you remember to run it and if the race happens during your test.<\/p>\nlet mut counter = 0;\nfor _ in 0..100 {\n std::thread::spawn(|| {\n counter += 1; \/\/ error: closure may outlive borrowed value\n });\n}\n<\/code><\/pre>\nArc<Mutex<i32>><\/code> or an atomic, and the compiler makes you say which. Annoying on day one. Excellent on day two hundred.<\/p>\nResult<\/code> that you don’t handle is a warning at minimum, and with #[must_use]<\/code> semantics on most APIs, ignoring it is deliberate. Go’s if err != nil<\/code> is fine, but nothing stops you writing val, _ := doThing()<\/code> at 2am, and I have.<\/p>\nWhere Go actually earns it<\/h2>\n
Send<\/code> bounds on your futures, and you occasionally end up in a fight about lifetimes inside a spawned task. It’s got much better. It’s still more moving parts than go func()<\/code>. I went into which runtime I’d settle on in my Rust async runtime comparison<\/a>.<\/p>\nnet\/http<\/code> is production-grade out of the box. log\/slog<\/code> is in the standard library now. encoding\/json<\/code> is there. For a normal HTTP service you can go a long way on the standard library alone, which keeps your dependency tree small and your supply chain narrow.<\/p>\nThe heuristic I actually use<\/h2>\n
\n
\n
The rewrite question<\/h2>\n
Something to try this week<\/h2>\n
Result<\/code> without also fighting a runtime and a framework at the same time, and you’ll know within a weekend whether the model clicks for you.<\/p>\n