Backends — Go vs Rust

Both backends serve the same /products endpoints. The contrast is in how the SQL is written and checked — sqlc generates Go from a .sql file offline; sqlx checks inline SQL against a live database at compile time.

Each warehouse query sleeps a per-warehouse latency_ms to simulate a remote call. Sum of latencies = 400 ms; max = 150 ms. Both backends complete in ~150 ms — the test asserts < 400 ms to catch any regression to serial execution.

A 7-state order lifecycle. The Rust transition table is a match with no catch-all — adding a new variant refuses to compile until handled. The Go switch has no such guarantee; new states silently get no transitions.

A single ticker per backend mutates an owned price cache and fans out updates to every connected WebSocket subscriber. tokio::sync::broadcast::Sender wraps the fan-out in ~20 lines; the equivalent Go hub is ~50 lines of map + RWMutex + per-client channel.

One webhook endpoint, three event shapes (payment.succeeded, payment.failed, refund.created). Rust's serde reads the discriminator and lifts the right variant in one pass; Go has to do a two-step parse via an envelope of json.RawMessage fields.

Every other page on this site argues for Rust. This one doesn't. Five places where Go is the right call — compile times, onboarding cost, deployment artifact, stdlib breadth, and the everyday cost of writing a service.

Delete a column from your migration and rebuild. sqlx::query! refuses to compile and tells you exactly which call site references the missing column. No tests, no DB roundtrip in production code, no surprise at 3am.

GET /products/{slug}/recommendations scores every other product against the target with a CPU-bound similarity hash. Go fans out one goroutine per candidate writing to its own slot in a slice. Rust hands the slice to rayon::par_iter and lets the work-stealing pool spread it across threads.

A periodic background worker that advances paid orders through the fulfillment chain. SIGTERM must stop the loop without aborting an in-flight transition. Go uses context.Context + sync.WaitGroup; Rust uses tokio::select! on a oneshot signal plus an awaited JoinHandle.

100 requests per second per IP, fixed window, in memory. The Go side is one function (func(http.Handler) http.Handler) wired in via chi's r.Use. The Rust side is a Layer + a Service impl — two trait impls and a poll_ready dance — for the same outcome.

Go developers reach for an interface the moment they want to test something. Rust has three takes on the same shape — concrete, dyn via async_trait, native generics — and none of them is as ergonomic as Go's implicit interfaces. This page makes that comparison directly.