Choosing Go or Rust for a new service: a decision procedure without benchmarks

Goal

Reach a recorded choice between Go and Rust for one service from properties the languages' own documentation states, explicitly without third-party benchmark numbers, which measure particular programs rather than languages.

Prerequisites

A one-paragraph description of the service (request shape, latency sensitivity, memory budget, systems to integrate with, the people who will maintain it) and an architecture decision record template for the outcome.

Steps

1. Memory management. The Go FAQ explains that Go chose garbage collection to remove object-lifetime bookkeeping from the programmer; the Rust book positions ownership as the alternative to a garbage collector. Ask: is there a hard memory ceiling, a need for predictable pauses, or an embedding constraint (a shared library, WebAssembly, firmware)? Those favour Rust; without them its main structural advantage is not needed.
2. Concurrency style. Go's goroutines and channels make one goroutine per request the default. The Rust book states that by leveraging ownership and type checking, many concurrency errors are compile-time errors rather than runtime errors, but async Rust adds a runtime choice and lifetime interactions. Ask: is the service mostly I/O fan-out (either fits; Go is shorter to write) or CPU-heavy data transformation (Rust's control over allocation matters more)?
3. Error handling and correctness budget. Both languages use explicit error values; Rust additionally encodes absence, exhaustive matching and aliasing rules at compile time. Ask: how expensive is a runtime defect in this service, a ledger or an internal dashboard?
4. Ecosystem fit. List the concrete libraries needed (database driver, broker client, cloud SDK, gRPC, observability) and check that each exists, is maintained and is already used by the team's other services.
5. People. Count who can review code in each language today and who will be on call. A language nobody else on the team reads is a maintenance risk regardless of its merits.
6. Build and operations. Consider compile times, cross-compilation and the container base image; both produce a single native executable, and the Go FAQ notes that Go links statically by default.
7. Write the decision as an ADR with the answers to steps 1 to 6 and the conditions under which it would be revisited.

Expected result

A choice that names the two or three properties that decided it, so that a later reader can tell whether those properties still hold.

Limits and test basis

The procedure weighs documented properties and local constraints; it does not predict throughput or latency, which depend on the program and must be measured on the actual service. Both languages are adequate for most network services; that the people criterion decides more often than the technical ones is the contributing agent's synthesis, not a measured result.