net\/http<\/code>, encoding\/csv<\/code>, and encoding\/json<\/code>. Around 280 lines.<\/p>\nThe Rust version used axum 0.7, serde, the csv<\/code> crate, and tokio. Around 340 lines.<\/p>\nBoth ran behind the same nginx sidecar on a small Hetzner box. I stress-tested each one with oha<\/code> at 500 concurrent connections.<\/p>\nWhere Go wins on actual delivery speed<\/h2>\n
![\"Rust](\"https:\/\/abrarqasim.com\/blog\/wp-content\/uploads\/2026\/04\/rust-vs-go-2026-what-i-reach-for-inline-1776344492.png\")
<\/p>\n
I had the Go version running end-to-end in about 90 minutes. The Rust version took the better part of a day, and I’ve written real Rust for three years.<\/p>\n
Most of that gap isn’t the compiler fighting me. It’s the ecosystem. In Go, encoding\/csv<\/code> is in the standard library and it just works. In Rust, you pick between the csv<\/code> crate, csv-async<\/code>, or rolling your own streaming parser, and the second you want async reading, the decision tree splinters across three or four crates.<\/p>\nHere’s the Go handler that does almost everything:<\/p>\n
func transform(w http.ResponseWriter, r *http.Request) {\n reader := csv.NewReader(r.Body)\n reader.FieldsPerRecord = -1\n enc := json.NewEncoder(w)\n header, err := reader.Read()\n if err != nil {\n http.Error(w, err.Error(), 400)\n return\n }\n for {\n row, err := reader.Read()\n if err == io.EOF {\n return\n }\n if err != nil {\n http.Error(w, err.Error(), 400)\n return\n }\n out := make(map[string]string, len(header))\n for i, h := range header {\n out[h] = row[i]\n }\n if err := enc.Encode(out); err != nil {\n return\n }\n }\n}\n<\/code><\/pre>\nThat reads, transforms, and streams. Any Go dev on the team can maintain it without a walkthrough. The equivalent Rust handler with axum and an async csv<\/code> wrapper was about twice the length, mostly because I had to thread generic bounds through the streaming body type.<\/p>\nIf “ship it by Friday” is the constraint, Go is still the right tool. Rust asks you to make more decisions upfront, and a lot of them don’t pay off on a 300-line service.<\/p>\n
Where Rust wins once the code is alive<\/h2>\n
The interesting thing happened after I had been running both for a week.<\/p>\n
The Go version had three panics in production over the first week. All three were the same category: I had missed a nil check on a map lookup deep in the validation code. A runtime panic in a goroutine that I didn’t recover, which crashed the request handler cleanly, but still, three bugs I shouldn’t have shipped.<\/p>\n
The Rust version had zero. Not because I’m a better Rust programmer (I’m not) but because the type system wouldn’t let me deploy the bug. Option<T><\/code> forced me to handle the missing case at the place where it mattered, not three call frames later.<\/p>\nThis is the real Rust sales pitch for me. Not performance. Not memory. The fact that the set of things that can go wrong at runtime is genuinely smaller.<\/p>\n
Here’s the Rust validator I ended up with:<\/p>\n
async fn validate_row(\n row: &StringRecord,\n schema: &Schema,\n) -> Result<ValidatedRow, ValidationError> {\n let name = row.get(schema.name_idx)\n .ok_or(ValidationError::MissingField("name"))?;\n let age: u32 = row.get(schema.age_idx)\n .ok_or(ValidationError::MissingField("age"))?\n .parse()\n .map_err(|_| ValidationError::BadType("age"))?;\n Ok(ValidatedRow { name: name.into(), age })\n}\n<\/code><\/pre>\nEvery error case shows up in the function signature. You can’t forget one.<\/p>\n
Memory and throughput: the numbers from my laptop<\/h2>\n
I ran both under oha -c 500 -n 50000<\/code> on the same Hetzner CX22:<\/p>\n