Rust apareceu na conversa de muitos times nos últimos anos como aquela linguagem que "todo mundo elogia mas ninguém usa em produção". Esse argumento perdeu força. Os dados de 2025 mostram uma mudança que não dá para ignorar: 45% das organizações entrevistadas na pesquisa oficial usam Rust em sistemas de produção não-triviais, um salto de 7 pontos percentuais em relação a 2023.

Não se trata mais de entusiastas experimentando no fim de semana. Estamos falando de times de engenharia que escolheram Rust para resolver problemas concretos e mediram os resultados.

Os números que mudaram a conversa

A pesquisa State of Rust 2024 (publicada em fevereiro de 2025) trouxe dados que consolidam uma tendência. 38% dos desenvolvedores Rust usam a linguagem na maior parte do seu trabalho profissional, contra 34% em 2023. Entre quem usa Rust, 53% programa nela diariamente.

O dado mais revelador talvez seja este: 82% dos respondentes afirmam que Rust ajudou suas empresas a atingir seus objetivos. Quando a satisfação com uma ferramenta está nesse patamar, a pergunta deixa de ser "devemos experimentar?" e passa a ser "por que ainda não estamos usando?"

No índice TIOBE, a adoção saltou de 1.05% para 1.47% entre 2024 e 2025, um crescimento relativo de 40%. Para uma linguagem de sistemas que exige curva de aprendizado íngreme, esse número é significativo.

O uso comercial cresceu 68.75% entre 2021 e 2024, segundo dados da JetBrains. Não é um spike. É uma linha que sobe consistentemente há quatro anos.

Do Discord à AWS: cases que provam o ponto

Falar de adoção enterprise sem exemplos concretos é falar no vazio. Dois cases se destacam pela clareza dos resultados.

O Discord enfrentava um problema persistente no serviço de Read States, o componente que rastreia quais canais e mensagens cada usuário já leu. Esse serviço é acessado toda vez que alguém conecta no Discord, toda vez que uma mensagem é enviada e toda vez que uma mensagem é lida. A implementação em Go funcionava bem na maior parte do tempo, mas a cada dois minutos sofria spikes de latência causados pelo garbage collector forçando coletas em um cache LRU grande.

A equipe reescreveu o serviço em Rust. Os resultados foram diretos: eliminação completa dos spikes, redução de 40% no uso de memória e latência até 160 vezes menor no pior caso. Uma otimização específica — trocar HashMap por BTreeMap no cache LRU — melhorou a eficiência de memória de forma que seria impossível na implementação Go, onde a estrutura do GC limitava as opções.

Do outro lado do espectro, a AWS construiu o Firecracker inteiramente em Rust. É a tecnologia de microVM que sustenta o AWS Lambda e o AWS Fargate. Os números: tempo de inicialização abaixo de 125 milissegundos, footprint de memória menor que 5 MiB por microVM e capacidade de criar 150 microVMs por segundo em um único servidor. Milhões de invocações Lambda passam pelo Firecracker diariamente.

Se existe um teste de estresse para uma linguagem, rodar a infraestrutura serverless da AWS se qualifica.

Além desses dois, Microsoft, Cloudflare, Dropbox e Meta usam Rust em produção para componentes de infraestrutura. A Cloudflare roda parte do seu edge runtime na linguagem. A Meta investe em Rust para backend. São escolhas independentes, de empresas com culturas de engenharia diferentes, que chegaram à mesma conclusão.

Rust no kernel Linux: o selo definitivo

Em dezembro de 2025 veio o marco mais simbólico: os mantenedores do kernel Linux declararam que Rust não é mais experimental. A linguagem passou de status experimental para componente permanente do kernel.

Greg Kroah-Hartman, um dos principais mantenedores, afirmou que drivers escritos em Rust têm se mostrado mais seguros que equivalentes em C. O kernel Linux 7.0 trouxe melhorias específicas no driver core para facilitar o uso de Rust em mais drivers: suporte a dev_printk em todos os tipos de device, ajuste de dma_set_max_seg_size() e I/O back-ends genéricos.

Os números absolutos ainda são modestos: cerca de 25 mil linhas de Rust contra 34 milhões de linhas de C. Mas a direção está clara, e o impacto prático já existe. Dispositivos Android 16 baseados no kernel 6.12 rodam o alocador de memória ashmem escrito em Rust. Milhões de celulares executam código Rust no kernel sem que seus donos saibam.

Para quem acompanha linguagens de sistemas, a aceitação no kernel Linux equivale a uma certificação de confiabilidade que nenhuma campanha de marketing consegue comprar.

O ecossistema async em 2026: Tokio completa uma década

Um dos argumentos históricos contra Rust era a imaturidade do ecossistema assíncrono. Esse argumento envelheceu mal.

2026 marca dez anos desde o anúncio do Tokio, o runtime async que virou padrão de facto. O projeto mantém versões LTS (1.43.x até março 2026, 1.47.x até setembro 2026) e faz releases mensais. O axum 0.8, framework web construído sobre Tokio, Tower e Hyper, trouxe uma ergonomia que era difícil imaginar nos primeiros anos do async Rust.

Um endpoint HTTP básico em axum se parece com isto:

use axum::{routing::get, Router};

async fn health() -> &'static str {
    "ok"
}

#[tokio::main]
async fn main() {
    let app = Router::new().route("/health", get(health));
    let listener = tokio::net::TcpListener::bind("0.0.0.0:3000")
        .await
        .expect("failed to bind");
    axum::serve(listener, app).await.expect("server error");
}

Sem macros obscuras, sem boilerplate excessivo. A composição com Tower middleware segue o mesmo padrão de camadas que desenvolvedores de Express ou Koa já conhecem, e a diferença é que erros de tipo são pegos em compilação.

O principal desafio restante é diagnosticar tasks travadas e latência de cauda alta. É problema de operação, não de viabilidade. Ferramentas de análise estática específicas para async estão em desenvolvimento ativo.

O TokioConf 2026, marcado para abril em Portland, é outro sinal de maturidade: uma conferência dedicada a aplicações assíncronas em Rust não existiria se o ecossistema ainda fosse nicho.

O custo real de adotar Rust

Seria desonesto falar só das vitórias. Adotar Rust tem custos que precisam estar na mesa antes da decisão.

A curva de aprendizado é real. O borrow checker, que garante segurança de memória em tempo de compilação, exige repensar como se estrutura código. Desenvolvedores vindos de Go, Python ou TypeScript relatam semanas até se sentirem produtivos e meses até dominarem lifetimes explícitas e trait bounds complexos.

Tempo de compilação é outro ponto de fricção. Projetos grandes compilam significativamente mais devagar que equivalentes em Go. Compilação incremental ajuda, mas builds limpos continuam lentos.

A contratação também pesa. O pool de desenvolvedores Rust é menor que o de Go, Python ou Java. Isso significa salários mais altos, processos seletivos mais longos, ou investir em treinar o time existente.

Em benchmarks sintéticos, servidores Rust com Actix-web processam cerca de 60 mil requisições por segundo contra 40 mil de equivalentes em Go com Fiber, embora os números variem conforme hardware e configuração de teste. O uso de memória fica entre 50-80 MB no Rust contra 100-320 MB no Go. A diferença existe, mas a pergunta que importa é: o caso de uso precisa dessa diferença?

Para a maioria dos CRUDs e APIs REST, Go entrega performance mais que suficiente com metade do tempo de desenvolvimento. Rust faz sentido quando latência previsível importa, quando uso de memória é gargalo, ou quando segurança de memória é requisito de negócio: infraestrutura de cloud, sistemas financeiros, firmware, componentes de kernel.

Conclusão

A narrativa mudou. Os resultados em produção falam por si. A adoção cresceu 40% em um ano, o Linux declarou a linguagem como componente permanente do kernel, e empresas como AWS rodam infraestrutura crítica nela todos os dias.

Isso não significa que todo time deveria migrar para Rust amanhã. Significa que a decisão entre Rust e outras linguagens hoje é uma decisão pragmática sobre trade-offs: curva de aprendizado e tempo de compilação de um lado, segurança de memória e performance previsível do outro.

O Rust de 2026, com ecossistema async maduro e adoção enterprise comprovada, é uma ferramenta séria para problemas sérios. E pela primeira vez, "experimental" não é mais uma desculpa válida para ignorá-la.

Referências pesquisadas nesta publicação