Go or Rust for a JSON over HTTP service that two people have to maintain

Numbers from our migration, because everyone quotes benchmarks that are not their workload. Our Rust service idles around 25MB resident, the Go equivalent around 60MB with GC headroom, and under our actual load the p99 difference was around three milliseconds on a request that spends 40 milliseconds waiting on Postgres. So the difference was real, measurable, and completely irrelevant to us. If your p99 is dominated by database round trips, and at 30 CRUD endpoints it almost certainly is, the language is not where your latency lives.

I have written the same shape of service in both, one at work and one as a rewrite, so here is the concrete comparison. The Go version was about 30 percent fewer lines, took me four days, and compiles in under two seconds so the edit loop never breaks your concentration. The Rust version with axum and sqlx took nine days, most of which was two afternoons fighting lifetimes in middleware and one day learning how compile time query checking wants your migrations laid out, and a clean release build is around a minute. Two years on, the Rust one has had no production incidents and the Go one has had three nil pointer panics, all of which were my fault and all of which a stricter compiler would have caught. For six weeks and two Python people, Go.

I want to push back on the reflexive just use Go answer, because the ecosystem argument is a lot weaker than it was. axum plus sqlx plus serde is a genuinely pleasant stack now, the borrow checker cost is front loaded into weeks one to three and then largely disappears for web services where everything is owned per request, and serde has saved me more JSON bugs than I can count. The two person part cuts both ways: with a small team you cannot afford the runtime surprises either. I would still not do it with a six week deadline and zero Rust experience, but I would not frame it as Rust being unsuitable, only as the timing being wrong.

Six weeks, two Python people, one of them has touched Go. That is the answer, the rest is preference. Learn Rust on something that is not on a deadline.

We picked Rust in almost exactly your situation and it went badly for a reason that had nothing to do with the language. The person who actually understood it left after fourteen months, the rest of us could read it but could not confidently change it, and a feature that should have taken two days took two weeks because nobody wanted to touch the trait soup in the middleware. We ended up porting the boring half to Go. If you write Rust, write the dullest possible Rust and make sure both of you have hands on every module.