Frameworks Rust em 2025: qual escolher para web

Introdução: Por que Rust e por que agora?

Se você está lendo este texto, provavelmente já conhece a magia do Rust — a linguagem que oferece a velocidade do C++ com segurança de memória, sem te deixar dar tiros no pé (quase). Em 2025, o ecossistema de frameworks web Rust vive um verdadeiro renascimento. Saímos da era das bibliotecas "cruas" e entramos na era das soluções maduras e prontas para produção.

Neste artigo, não vamos apenas listar nomes. Vamos analisar os quatro principais frameworks — Actix-web, Axum, Rocket e Warp — sob a ótica de projetos reais. Você tem um projeto pessoal com um milhão de requisições ou uma API corporativa? Vamos descobrir juntos.

Critérios de escolha: o que observar em 2025?

Antes de mergulhar no código, vamos definir as métricas. Para nós, o que importa é:

\n
• Desempenho (throughput e latência) — Rust não perdoa frameworks lentos.
\n
• Ergonomia e DX (Experiência do Desenvolvedor) — quanto tempo você gasta configurando, em vez de programar a lógica.
\n
• Ecossistema e suporte — middleware, bancos de dados, WebSocket, gRPC.
\n
• Comunidade e longevidade — commits, issues, atualizações.
\n

1. Actix-web: O veterano que não desiste

Actix-web foi por muito tempo o rei dos benchmarks. É rápido, agressivo e passou pelo drama da saída do criador e seu retorno. Em 2025, é um projeto estável e maduro, mantido pela comunidade.

Pontos fortes:

\n
• Desempenho máximo: Actix ainda lidera em RPS (requisições por segundo).
\n
• Ecossistema rico: tem de tudo — de WebSocket a SSE.
\n
• API estável: poucas mudanças críticas no último ano.
\n

Pontos fracos:

\n
• Sistema de traits complexo: iniciantes podem sofrer com HttpResponse e Handler.
\n
• Assincronicidade: roda no próprio actix_rt, o que às vezes conflita com outros runtimes.
\n

Exemplo de código: API REST simples

use actix_web::{web, App, HttpServer, Responder};\n\nasync fn hello() -> impl Responder {\n    "Olá do Actix-web 2025!"\n}\n\n#[actix_web::main]\nasync fn main() -> std::io::Result<()> {\n    HttpServer::new(|| {\n        App::new()\n            .route("/", web::get().to(hello))\n    })\n    .bind("127.0.0.1:8080")?\n    .run()\n    .await\n}

Veredito: Escolha Actix-web se você precisa extrair o máximo do hardware e não tem medo de trabalhar profundamente com tipos.

2. Axum: A escolha pragmática da equipe Tokio

Axum (dos criadores do Tokio e Hyper) é o padrão moderno. Ele é construído em torno do tower (Service), o que o torna incrivelmente flexível. É o framework para quem quer "configurar, não reescrever".

Pontos fortes:

\n
• Integração com o ecossistema Tokio: se você usa tokio::main, Axum é seu amigo.
\n
• Modularidade: middleware são adicionados como camadas (layers).
\n
• Extractors: trabalhar com JSON, Path, Query é básico, mas feito de forma impecável.
\n

Pontos fracos:

\n
• Juventude: alguns recursos (como WebSocket nativo) exigem configuração manual.
\n
• Erros de compilação complexos: se algo der errado com os traits, o compilador vai te dar um "tijolo".
\n

Exemplo de código: API JSON com estado

use axum::{\n    extract::State,\n    routing::get,\n    Json, Router,\n};\nuse std::sync::Arc;\n\n#[derive(Clone)]\nstruct AppState {\n    counter: Arc<std::sync::atomic::AtomicU64>,\n}\n\nasync fn get_count(State(state): State<AppState>) -> Json<u64> {\n    let count = state.counter.fetch_add(1, std::sync::atomic::Ordering::SeqCst);\n    Json(count + 1)\n}\n\n#[tokio::main]\nasync fn main() {\n    let state = AppState {\n