Dev Note

Introduction
For the past several years, the Rust hype cycle has been relentless. “Rust is the future of systems programming.” “Rust eliminated memory safety bugs.” “Rust is 10x faster than Go.” All true — in benchmarks and ideal conditions.
But here’s the question backend engineers actually need answered: Is Rust practical for building production web services in 2026?
I’ve spent the last 18 months building and maintaining a suite of backend services in Rust (and before that, Go and Node.js). Here’s the honest answer: yes, with important caveats. Rust has crossed the threshold from “impressive but painful” to “genuinely productive” — but only in specific contexts.
Photo by Émile Perron on Unsplash
The 2026 Rust Backend Ecosystem
The ecosystem has matured dramatically. The key pieces:
Axum + Tokio: The Standard Stack
If you’re building a web API in Rust in 2026, you’re almost certainly using Axum on top of Tokio. This has become the clear winner over Actix-Web, Warp, and Rocket.
use axum::{
    extract::{Path, State},
    http::StatusCode,
    response::Json,
    routing::{get, post},
    Router,
};
use serde::{Deserialize, Serialize};
use sqlx::PgPool;
use std::sync::Arc;
#[derive(Clone)]
struct AppState {
    db: PgPool,
}
#[derive(Serialize, Deserialize)]
struct User {
    id: i64,
    email: String,
    name: String,
    created_at: chrono::DateTime<chrono::Utc>,
}
#[derive(Deserialize)]
struct CreateUserRequest {
    email: String,
    name: String,
}
async fn get_user(
    State(state): State<Arc<AppState>>,
    Path(user_id): Path<i64>,
) -> Result<Json<User>, StatusCode> {
    sqlx::query_as!(
        User,
        "SELECT id, email, name, created_at FROM users WHERE id = $1",
        user_id
    )
    .fetch_optional(&state.db)
    .await
    .map_err(|_| StatusCode::INTERNAL_SERVER_ERROR)?
    .map(Json)
    .ok_or(StatusCode::NOT_FOUND)
}
async fn create_user(
    State(state): State<Arc<AppState>>,
    Json(payload): Json<CreateUserRequest>,
) -> Result<(StatusCode, Json<User>), StatusCode> {
    let user = sqlx::query_as!(
        User,
        "INSERT INTO users (email, name) VALUES ($1, $2) RETURNING id, email, name, created_at",
        payload.email,
        payload.name
    )
    .fetch_one(&state.db)
    .await
    .map_err(|_| StatusCode::INTERNAL_SERVER_ERROR)?;
    
    Ok((StatusCode::CREATED, Json(user)))
}
#[tokio::main]
async fn main() -> anyhow::Result<()> {
    let database_url = std::env::var("DATABASE_URL")?;
    let db = PgPool::connect(&database_url).await?;
    
    // Run migrations at startup
    sqlx::migrate!("./migrations").run(&db).await?;
    
    let state = Arc::new(AppState { db });
    
    let app = Router::new()
        .route("/users/:id", get(get_user))
        .route("/users", post(create_user))
        .with_state(state);
    
    let listener = tokio::net::TcpListener::bind("0.0.0.0:3000").await?;
    println!("Listening on :3000");
    axum::serve(listener, app).await?;
    
    Ok(())
}
This is clean, readable code. The borrow checker isn’t fighting you. The type system is helping you.
SQLx: Compile-Time Query Verification
This deserves special mention. SQLx verifies your SQL queries against your actual database schema at compile time. That’s not a runtime check — it’s a compile-time check.
// This fails to compile if the query is wrong, the table doesn't exist,
// or the column types don't match the Rust types
let users = sqlx::query_as!(
    User,
    "SELECT id, email, name, created_at FROM users WHERE created_at > $1",
    cutoff_date
)
.fetch_all(&pool)
.await?;
In 6 months of development, I have had zero SQL-related runtime errors in production. Zero. That’s remarkable.
The Essential Crates in 2026
[dependencies]
# Async runtime
tokio = { version = "1", features = ["full"] }
# Web framework
axum = { version = "0.8", features = ["macros"] }
# Database
sqlx = { version = "0.8", features = ["runtime-tokio", "postgres", "chrono", "uuid"] }
# Serialization
serde = { version = "1", features = ["derive"] }
serde_json = "1"
# Error handling
anyhow = "1"
thiserror = "2"
# Async HTTP client
reqwest = { version = "0.12", features = ["json"] }
# Observability
tracing = "0.1"
tracing-subscriber = { version = "0.3", features = ["env-filter", "json"] }
opentelemetry = "0.27"
tracing-opentelemetry = "0.28"
# Validation
validator = { version = "0.19", features = ["derive"] }
# JWT
jsonwebtoken = "9"
# Configuration
config = "0.14"
# Date/time
chrono = { version = "0.4", features = ["serde"] }
Where Rust Genuinely Wins
1. High-Throughput, CPU-Bound Services
If your service is doing real computation — parsing, encoding, cryptography, ML inference, data transformation — Rust delivers. A Rust service processing JSON streams uses ~5-10x less CPU than an equivalent Go service, and the latency tail (p99, p999) is dramatically better due to zero GC pauses.
Real numbers from our payment processing service (migrated from Go):
P50 latency: 12ms → 3ms
P99 latency: 85ms → 9ms
CPU usage: 4 vCPUs → 1 vCPU at same throughput
Memory: 512MB → 48MB
2. Long-Running Connection Handlers
WebSocket servers, streaming APIs, multiplexed connection pools — Rust’s async/await with Tokio is exceptional here. The combination of zero-overhead async and no GC means you can handle 100k+ concurrent connections on modest hardware.
3. Services That Must Not Crash
The borrow checker eliminates entire categories of bugs: use-after-free, data races, null pointer dereferences. In 18 months of production Rust services, we’ve had zero memory-safety incidents. Zero panics in production code (we treat unwrap/expect as code review failures).
4. CLI Tools and Developer Tooling
If you’re building internal tools — data pipelines, deployment scripts, code generators — Rust makes excellent CLIs with the clap crate. Single binary, no runtime dependency, fast startup.
Where Rust Still Struggles
1. Iteration Speed
The compile-check-iterate cycle is slower than Go or Python. For a service under active feature development, the borrow checker can feel like fighting quicksand. Expect 2-3x slower development velocity for junior Rust engineers vs. experienced Go engineers.
This is improving — cargo check is fast, incremental compilation has gotten better, and tooling like rust-analyzer is excellent. But it’s still a real cost.
2. Async Is Still Complicated
async Rust is powerful but not simple. The Send + Sync + 'static bounds propagate everywhere. Async traits are finally stable (no more async-trait crate) but the mental model is still complex.
// This is valid Rust but understanding WHY requires significant study
async fn process<T>(value: T) -> impl Future<Output = Result<(), Error>>
where
    T: Send + Sync + 'static + Serialize,
{
    async move {
        // ...
    }
}
3. Macros Are Magic
Rust’s procedural macros (like SQLx’s query_as!, Serde’s #[derive(Serialize)], Axum’s #[debug_handler]) are incredibly powerful — but when they fail, error messages are cryptic. Debugging macro errors is a skill unto itself.
4. Hiring Is Hard
The Rust talent pool, while growing, is still much smaller than Go or Python. Senior Rust engineers command significant salary premiums. For startups hiring quickly, this matters.
Rust vs. Go in 2026: The Honest Comparison
This question comes up constantly. Here’s my take:
Criterion
      Rust
      Go
    
Raw performance
      ⭐⭐⭐⭐⭐
      ⭐⭐⭐⭐
    
Latency tail (p99+)
      ⭐⭐⭐⭐⭐
      ⭐⭐⭐
    
Memory usage
      ⭐⭐⭐⭐⭐
      ⭐⭐⭐⭐
    
Development speed
      ⭐⭐⭐
      ⭐⭐⭐⭐⭐
    
Hiring ease
      ⭐⭐
      ⭐⭐⭐⭐
    
Error handling
      ⭐⭐⭐⭐⭐
      ⭐⭐⭐
    
Correctness guarantees
      ⭐⭐⭐⭐⭐
      ⭐⭐⭐
    
Ecosystem maturity
      ⭐⭐⭐⭐
      ⭐⭐⭐⭐⭐
    
Learning curve
      Hard
      Easy
    
Use Rust when: Performance is a first-class constraint, correctness matters enormously, or you’re building infrastructure/tooling.
Use Go when: You need to move fast, hire quickly, or the performance of Go is “good enough” (which is most web services).
Photo by Florian Olivo on Unsplash
A Production-Ready Service in Rust: Structure
Here’s the project structure we’ve converged on for production Rust services:
my-service/
├── Cargo.toml
├── Cargo.lock
├── migrations/
│   ├── 001_initial.sql
│   └── 002_add_indexes.sql
├── src/
│   ├── main.rs          # Entry point, server setup
│   ├── config.rs        # Configuration loading
│   ├── error.rs         # Custom error types
│   ├── state.rs         # AppState, shared resources
│   ├── routes/
│   │   ├── mod.rs
│   │   ├── users.rs
│   │   └── health.rs
│   ├── services/        # Business logic
│   │   ├── mod.rs
│   │   └── user_service.rs
│   ├── models/          # Domain types
│   │   ├── mod.rs
│   │   └── user.rs
│   └── middleware/      # Auth, logging, etc.
│       ├── mod.rs
│       └── auth.rs
├── tests/
│   └── integration_test.rs
└── Dockerfile
The Dockerfile is refreshingly simple:
# Build stage
FROM rust:1.83-slim as builder
WORKDIR /app
COPY . .
RUN cargo build --release
# Runtime stage — the final image is tiny
FROM debian:bookworm-slim
COPY --from=builder /app/target/release/my-service /usr/local/bin/
EXPOSE 3000
CMD ["my-service"]
Final image size: ~15MB. No runtime dependencies. No interpreter. No JVM.
The Verdict
In 2026, Rust is practical for backend development — with eyes open.
Invest in Rust if:
Your service is performance-critical (high throughput, low latency)
Correctness is paramount (financial systems, infrastructure)
You’re building long-lived infrastructure that won’t change frequently
Your team already has or is committed to building Rust expertise
Stick with Go, Python, or Node.js if:
You need to move fast and ship features
You’re a small team where hiring generalists matters
Your service is I/O bound (in which case Go’s performance is plenty)
You’re building internal tooling or prototypes
The borrow checker stops being an enemy once you internalize its rules. The compile times stop being annoying once you have a good cargo watch workflow. The ecosystem is mature enough that you’re rarely reaching for a half-baked crate.
Rust in 2026 isn’t magic. But for the right workloads, it’s genuinely excellent.
Resources
The Rust Programming Language Book
Axum Documentation
SQLx
Tokio
Zero to Production in Rust — the best book for Rust web dev

Rust for Backend Development in 2026: Is It Finally Practical?

댓글