Análise da linguagem de programação Rust: vale a pena aprender?

Pergunte a dois devs Rust experientes se aprender Rust valeu o esforço e você pode ouvir respostas completamente opostas. Um pode dizer que não fez nada pela carreira dele; outro pode chamar de uma das melhores decisões técnicas que já tomou. Os dois podem estar certos.

É nessa contradição que a pergunta “vale a pena aprender Rust” realmente está, e é por isso que um sim genérico não serve para nada. Rust é uma linguagem compilada cujo subconjunto seguro impõe regras de segurança de memória em tempo de compilação, sem exigir um garbage collector em tempo de execução.

Então vou me comprometer com uma resposta, dizer de que condição ela depende e mostrar quanto essa condição custa.

A versão curta

Vale a pena aprender Rust se você está construindo algo de vida longa em que ter o compilador pegando uma classe inteira de bugs compensa o preço. É a escolha errada se você precisa entregar um app CRUD este mês, está aprendendo a programar ou está contando vagas de emprego. 4 de 5, com desconto pelo que custa antes de dar retorno.

• O que você está comprando: no Rust seguro, as regras de ownership e borrowing transformam bugs de use-after-free, double-free, referência inválida e data race em erros de compilação, e não em incidentes em produção. Esse é o argumento todo, e é um bom argumento.
• O que você está pagando: o compilador obriga você a escrever decisões de memória que sua linguagem atual toma em silêncio, e no começo parece que a ferramenta está criando dificuldade.
• A questão da durabilidade está resolvida. Os mantenedores do kernel concluíram o experimento com Rust no Maintainers Summit de dezembro de 2025, e o rótulo de “experimental” saiu no Linux 7.0.
• A questão da moda não está resolvida, e é outra pergunta. Rust está em #10 no índice TIOBE de setembro de 2026, acima do #18 de um ano antes.
• Meu serviço Rust de teste precisou de muito mais memória para compilar do que para rodar: chegou a quase 1 GB no build e ficava em cerca de 3,5 MB ocioso, rodando.
• Serve para você se você já entrega software em outra linguagem e está construindo algo em que um bug de memória sairia caro, ou trabalha perto de software de sistema. Não serve para você se você tem um prazo, está começando do zero ou procura a linguagem com mais vagas.

Como esta análise foi feita: os números de build e de execução aqui são meus. Instalei o Rust 1.98.1, escrevi um pequeno serviço web com Axum e medi o que ele exigia para compilar e o que exigia para rodar. Tudo rodou em um container isolado, não em hardware dedicado, e é um projeto só, então trate os números como um dado e não como uma lei. Todo o resto vem de fontes primárias ou confiáveis: o patch do kernel e a cobertura do LWN sobre ele, os posts de segurança do Android do Google, o próprio índice do TIOBE (com o comentário de abril pelo registro do Slashdot), o Phoronix sobre a janela de merge do Linux 7.0, os registros de CVE do kernel Linux para a vulnerabilidade do Binder, a própria declaração da Canonical e a pesquisa Stack Overflow de 2025. Li o patch do kernel. Não auditei o código Rust do kernel. E não escrevo Rust há anos, então, onde esta análise julga a linguagem em si, ela se apoia em profissionais que escrevem, e cita o nome deles.

O que o compilador entrega para você

Dê a duas threads uma referência mutável para o mesmo vetor em Rust e o código não compila. Não é um warning. Não é um lint que você pode silenciar na correria. Não compila. Essa recusa é o que você está comprando no Rust seguro: bugs de use-after-free, double-free, referência inválida e data race viram erros de compilação em vez de incidentes em produção. A válvula de escape do Rust (unsafe) pode contornar algumas dessas garantias, então não é uma promessa absoluta sobre qualquer base de código Rust.

Ownership quer dizer que todo valor tem exatamente um dono responsável por liberá-lo. Borrowing quer dizer que você pode emprestar referências, mas o compilador acompanha os lifetimes delas e não deixa nenhuma viver mais do que aquilo para que aponta, nem deixa um empréstimo mutável coexistir com qualquer outro. No Rust seguro, bugs de use-after-free, double-free, referência inválida e data race são pegos pelo sistema de ownership e de tipos antes de o programa rodar.

Não existe garbage collector, e essa é a outra metade do acordo. Como o ownership já diz quem libera o quê e quando, nada precisa percorrer o seu heap em tempo de execução. Você entrega um binário sem coletor dentro, e não tem tempos de pausa para ajustar.

O preço aparece no mesmo lugar que a garantia. Cada decisão de memória que sua linguagem atual toma em silêncio por você é uma que o Rust pede para você escrever: quem é dono disto, quanto tempo aquela referência vive, se mais alguma coisa pode vê-la e se ela cruza a fronteira de uma thread. O compilador não está criando dificuldade. Ele está se recusando a adivinhar.

Então: esse é o motivo pelo qual alguém paga o que o Rust pede, e acho que ele se sustenta. Se a classe de bugs que ele elimina não é uma que preocupa você, o resto desta análise provavelmente não vai mudar sua opinião.

Rust ainda é experimental ou já virou infraestrutura de produção?

Deixou de ser experimental em dezembro de 2025, e quem encerrou o experimento foram os próprios mantenedores do kernel. No Maintainers Summit de 2025, eles concluíram que o Rust tinha provado seu valor no kernel, técnica e socialmente. Jonathan Corbet, do LWN, relatou o consenso em 10 de dezembro de 2025: Rust no kernel não é mais experimental.

O Rust entrou no Linux mainline na v6.1 em 2022 justamente para fazer esse experimento. O patch de Miguel Ojeda removendo o rótulo veio três dias depois do Summit, e entrou na janela de merge do Linux 7.0.

“Mas o experimento acabou, ou seja, o Rust veio para ficar.”

Miguel Ojeda, “rust: conclude the Rust experiment”, LKML, 13 de dezembro de 2025

À parte, e antes disso: a reescrita em Rust feita pelo Google do driver Binder do Android, a camada de IPC pela qual os processos do Android conversam (o tempo todo), entrou no Linux 6.18, lançado em 30 de novembro de 2025. Mantenha esse marco separado do consenso do Summit. É aquele em que uma empresa apostou um produto comercial no Rust do kernel, e não um grupo de mantenedores abençoando a ideia. Desde então, o Rust do kernel produziu seu primeiro CVE: CVE-2025-68260, uma condição de corrida nesse mesmo driver Binder que Greg Kroah-Hartman anunciou em 16 de dezembro de 2025, introduzida na 6.18 e corrigida na 6.18.1. Os primeiros relatos focavam em travamentos, mas a pontuação posterior da equipe de CVE do kernel Linux dá ao CVE-2025-68260 nota 7,8 (alta) e descreve um caminho de escalonamento local de privilégios por corrupção de memória do kernel. O mesmo driver (rust_binder) também acumulou outros CVEs desde então.

O Android é onde as evidências viram números. O blog de segurança do Google afirmou em dezembro de 2022 que tinham sido descobertas zero vulnerabilidades de segurança de memória no código Rust do Android, contra cerca de 1,5 milhão de linhas de Rust no AOSP e cerca de 21% de todo o código nativo novo no Android 13. É uma afirmação de 2022 com um escopo de 2022. Posts posteriores do Google mostram a tendência mais longa: problemas de segurança de memória responderam por 76% das vulnerabilidades do Android em 2019 e 24% em 2024, com a contagem bruta caindo de mais de 220 para 36 projetadas. Esses números só significam algo em relação à base que substituíram, que é C e C++ escritos por engenheiros muito bons com ferramentas muito boas.

Dois sinais menores apontam na mesma direção. O driver de GPU Apple AGX do Asahi Linux é em Rust, escrito pelo projeto Asahi Linux como um trabalho de engenharia reversa, e não pela Apple. A atualização da Canonical sobre o rust-coreutils diz que o Ubuntu 26.04 LTS traz o rust-coreutils 0.8.0 para a maioria dos utilitários. Três continuam no GNU coreutils (cp, mv, rm) porque oito problemas de TOCTOU ainda estavam abertos em 22 de abril de 2026; a Canonical mira a 26.10 para os utilitários restantes.

Este é o eixo em que eu daria a nota mais alta, e o motivo é o tipo de compromisso envolvido. Mantenedores do kernel não “desconcluem” experimentos, o Google não desfaz uma reescrita desse tamanho e a Canonical não coloca um coreutils reescrito numa LTS para ver no que dá. Aconteça o que acontecer com a popularidade do Rust, alguém vai ter que manter esse código por anos.

O Rust morreu ou só está se estabilizando?

Não. O Rust igualou sua melhor posição no TIOBE, a #13, em janeiro de 2026. Três meses depois tinha caído de volta para a #16, e o CEO do TIOBE, Paul Jansen, escreveu em abril de 2026, num comentário que o Slashdot citou na época, que o crescimento de popularidade do Rust “parece estar se estabilizando” e que uma posição no top 10 “agora parece mais distante do que antes”.

Ele estava descrevendo o Rust alcançando sua melhor posição de todos os tempos no próprio índice, um lugar que ocupou pela primeira vez em julho de 2024, e depois perdendo essa posição.

O índice TIOBE de setembro de 2026 coloca o Rust em #10, acima do #18 de um ano antes, e além do #13 que o TIOBE chamou de sua melhor posição de todos os tempos em janeiro.

Minha leitura: o platô foi real. Foi um vácuo de ar, não um teto. Isso supera a versão de cada lado, porque “o Rust empacou” agora está errado e “o Rust só sobe” nunca foi verdade.

A ressalva vale para os dois lados, e o texto do Slashdot já levantava isso na época: será que os rankings só estão oscilando com o ruído de um mês para o outro nos resultados de buscadores, que é o que o índice conta? Se uma queda de três posições em um trimestre era uma evidência fraca de que o Rust estava desacelerando, uma subida de seis posições é uma evidência fraca de que ele está ganhando. Trate isso como tempo, não como clima.

O sinal mais forte sobre sentimento é a pesquisa do Stack Overflow, onde o Rust é mais uma vez a linguagem de programação mais admirada em 2025, com 72%: pessoas que usaram no último ano e querem continuar usando. Isso é intenção de continuar, não adoção, e aqui é um sinal mais útil do que a popularidade bruta se você está decidindo se vai gostar de continuar com a linguagem.

O momento é ambíguo, e dou a ele menos peso do que à durabilidade acima, porque você não está investindo em um ranking.

Quanto custa aprender Rust

O custo chega cedo e de uma vez. Código que Python, Java ou C# rodariam sem reclamar é rejeitado, repetidamente, por motivos que parecem arbitrários até o modelo de ownership fazer sentido, e não dá para adiar isso. Você não consegue passar pelo borrow checker na base de ir entregando, do jeito que consegue passar por não entender direito o seu ORM.

Esta foi a parte que me surpreendeu, e ela vai no sentido contrário do que você esperaria. No thread “Struggling to learn Rust” do r/rust, a resposta que teve mais tração reformula o problema como falta de familiaridade, não dificuldade, e o thread aponta os devs experientes vindos de linguagens com garbage collector como os que sofrem mais. u/Voxelman diz isso sem rodeios: “Rust não é difícil. É diferente.” No mesmo thread, ele descreve o próprio caminho até ali: C64 Basic, depois uma série de linguagens imperativas, e um primeiro contato com Rust que “foi tudo menos WOW”, porque largar os velhos hábitos levou um tempo.

Esse é o formato da conta. Se você escreve Python há oito anos, não está aprendendo um conjunto de regras, está abrindo mão de um conjunto de suposições sobre quem limpa a bagunça depois de você. Quem sabe menos tem menos para desaprender.

Mais um padrão aparece repetidamente nesse thread, e ele transforma um erro de ordem num problema de confiança: as pessoas travam não no Rust, mas na escolha de um framework web, tentando aprender a linguagem por meio de Axum ou Actix antes de o ownership ter assentado. Como disse u/jmartin2683, isso é “como tentar aprender ruby aprendendo rails.”

Eu vejo a maioria dos alertas sobre o custo como apontando para a coisa errada. Reserve prática contínua, não um fim de semana, e não leia a frustração do começo como um veredito sobre a sua capacidade.

Rust precisa de uma máquina maior para compilar do que para rodar

Aqui está o resultado que eu não esperava: compilar este projeto Rust exigiu ordens de grandeza mais memória do que rodá-lo. Compilei um pequeno serviço Axum (Tokio com a feature full ativada, serde, serde_json, tower, uma rota JSON, cerca de 60 crates na árvore de dependências) no rustc e cargo 1.98.1, com strip = true no perfil release, e depois compilei do zero duas vezes:

# constrained: one compile job at a time
cargo build --release --jobs 1
# unconstrained: default parallelism, 4 vCPUs available
cargo build --release

Limitado a um job de compilação (--jobs 1), o pico de memória somando cargo, rustc e o linker ficou entre 464 MB e 527 MB, dependendo de qual dos meus dois métodos de medição você considera (medi de dois jeitos porque o primeiro número pareceu limpo demais), e levou 113 segundos. Com o paralelismo padrão em quatro vCPUs, o pico de memória praticamente dobrou, para cerca de 1 GB, e o build terminou em cerca de 35 segundos. A variável ali é o paralelismo, não o projeto. Mais jobs significam mais processos rustc residentes ao mesmo tempo, e é por isso que compiladores são uma das poucas cargas de trabalho que vão usar de bom grado cada núcleo que você der por minutos a fio.

O programa final tem 1,3 MB com strip, e fica ocioso usando cerca de 3,3 a 3,6 MB de memória.

No paralelismo padrão, isso dá de duzentas a trezentas vezes mais memória para compilar do que para rodar; limitado a um job, ainda é bem mais de cem vezes. Dimensione um servidor pelo que o seu serviço Rust precisa em produção e você pode acabar com uma máquina que não consegue compilá-lo, e a falha não é um erro limpo: é o OOM killer derrubando o rustc no meio do build, ou um compilador martelando o swap por vinte minutos. Duas respostas funcionam. Compilar em algum lugar com folga e enviar o binário, o mesmo padrão de manter uma máquina de build separada para trabalho pesado com Docker. Ou compilar na própria máquina e dar espaço a ela: para um serviço com esse formato, alguns gigabytes de RAM e duas vCPUs são confortáveis. Quando não são, a válvula de escape é --jobs 1 (sim, é mais lento; essa é a troca).

Se a máquina em que você trabalha não tem essa folga, nosso VPS Linux autogerenciado dá acesso root com cobrança por hora ou por mês e um lugar para colocar o build e devolver quando terminar, embora continue sendo um servidor que você opera, e não um que se opera sozinho.

Um projeto, um formato, uma máquina. A máquina era um container isolado compartilhado, não um servidor dedicado, com cerca de 2 GB de memória disponível, então o pico sem limite estava mais perto do teto do que estaria numa máquina maior. Isso não é uma constante universal: se sua árvore de dependências tem quatro vezes o tamanho ou seu perfil release liga a otimização em tempo de link, espere números diferentes. Árvores de dependências maiores, otimização em tempo de link e código com muitos genéricos podem elevar a memória de build, então não trate minhas medições como um teto universal.

Eu colocaria isso na conta de como você trabalha, não de se você aprende a linguagem. Saiba disso antes de dar de cara com o problema.

Quem deve aprender Rust

Três situações em que eu diria para você investir o tempo: software de vida longa em que um bug de memória sai caro, trabalho perto do sistema operacional e querer o que brigar com o compilador faz com o seu jeito de pensar em memória. Cada uma tem um motivo para esse tempo se pagar.

Você já entrega software em outra linguagem e está construindo algo de vida longa em que um bug de memória sairia caro. Um serviço que precisa ficar no ar. Uma biblioteca da qual outros times dependem. Qualquer coisa em que um use-after-free signifique uma análise de incidente, e não um stack trace no seu terminal. Este é o caso para o qual toda a garantia foi feita, e o que você paga no começo se amortiza ao longo da vida do que está construindo.

Você trabalha perto ou dentro de software de sistema. Drivers, trabalho com dispositivos, utilitários do sistema base, embarcados, qualquer coisa que fique abaixo de um sistema operacional em vez de em cima dele. A indústria se comprometeu aqui de um jeito que não se comprometeu em outros lugares, e é aqui que as evidências de segurança de memória são mais fortes.

Você quer o efeito colateral. Dois comentaristas daquele thread do r/rust discordam totalmente sobre o valor do Rust para a carreira e chegam ao mesmo ponto aqui. u/tyler_church, que diz que não teve impacto nenhum na carreira, ainda admite “talvez influências sutis em como eu escrevo outros programas em outras linguagens”. u/SirKastic23, há dois anos sendo pago para escrever Rust, diz que isso ampliou suas habilidades de programação de formas que nunca esperou. Duas pessoas, não um estudo, mas é o retorno que se mantém mesmo que você nunca escreva Rust profissionalmente: uma mudança no jeito de pensar, não uma linha no currículo.

Quem não deve aprender Rust

Três situações em que esse tempo é mais bem gasto em outra coisa: você tem um prazo este mês, está aprendendo a programar do zero ou está escolhendo uma linguagem pela quantidade de vagas que a mencionam. A terceira é a mais perguntada.

Você tem um prazo este mês para um app CRUD ou um protótipo. Rust chega exatamente no cronograma errado para um trabalho que precisa existir até sexta-feira. Go é a escolha óbvia no lugar dele se você quer uma linguagem compilada com builds rápidos e gerenciamento de memória com garbage collector, e não precisa das garantias baseadas em ownership do Rust.

Você está aprendendo a programar do zero. Este ponto realmente divide quem escreve Rust profissionalmente, e o desacordo nos threads do r/rust vai para os dois lados, então minha posição é que dar a um iniciante um cara ou coroa é um mau conselho, não importa para que lado a moeda caia. Aprenda primeiro como uma máquina funciona em algum lugar mais tolerante, depois volte e deixe o compilador apertar os parafusos.

Você está escolhendo uma linguagem pela quantidade de vagas que a mencionam. Não vou dar um número aqui, porque não encontrei nenhum dado de salário ou de vagas para Rust que leve a uma fonte que eu defenderia. O que u/crusoe descreve naquele thread do r/rust é um mercado com menos posições e mais especializadas. É um comentarista em um thread, não dados do mercado de trabalho, então eu não transformaria isso na afirmação de que vagas de Rust são escassas de modo geral. Se o volume de vagas é o seu fator decisivo, confira as vagas atuais no seu mercado-alvo antes de escolher a linguagem.

Perguntas frequentes