Em 2020, analistas do setor cravaram: o Rust entraria no top 10 do TIOBE em poucos anos. A linguagem subiu, subiu, e parou. Travou logo abaixo do topo, como um compilador que se recusa a deixar seu código passar. Irônico, não?

Os dados mais recentes do índice TIOBE confirmam o que muitos já suspeitavam nos corredores das empresas de tecnologia: a adoção corporativa do Rust estagnou. E o motivo não é técnico. É humano.

O memorando que ninguém conseguiu implementar

A pressão institucional era real. O Gabinete do Diretor Nacional de Cibersegurança dos EUA emitiu diretrizes rigorosas pedindo que a indústria abandonasse C e C++ em favor de alternativas com segurança de memória. Google incorporou Rust ao Android. Microsoft reescreveu pedaços do kernel do Windows. AWS bancou comitês fundadores do ecossistema open source.

As empresas de médio porte leram o memorando e fizeram o que sempre fazem: tentaram copiar as big techs. Iniciaram reescritas completas de código-fonte, apostando que o rótulo de “linguagem mais amada” do Stack Overflow se traduziria em adoção rápida e indolor.

Não traduziu.

Seis meses de produtividade no lixo, e a conta chega no board

Quem já colocou um time de devs acostumados com Python ou Java para escrever Rust sabe o que acontece: o compilador vira um chefe tirano. Ele não compila. Não negocia. Não aceita “depois eu arrumo”. Se o código pode vazar memória ou criar uma condição de corrida, ele simplesmente trava na sua cara.

A produtividade despenca nos primeiros seis meses. As equipes entregam funcionalidades numa velocidade que faz o gerente de engenharia perder o sono, e o argumento na reunião de budget. A busca pela perfeição técnica cobra um preço concreto: agilidade no mercado.

E quando o engineering manager tenta explicar pro CFO que “estamos mais lentos, mas mais seguros”, a conversa raramente termina bem.

O talento que não existe (e quando existe, custa uma fortuna)

O mercado de devs Rust é um deserto com três oásis cobrando preço de champagne.

Quando uma empresa abre uma vaga sênior exigindo conhecimento profundo em borrow checker, o funil de candidatos simplesmente evapora. Nesse ecossistema, não dá pra fingir. O engenheiro ou domina lifetimes e ownership models, ou não entrega código funcional. Sem meio-termo.

Os salários desses especialistas se descolaram completamente das tabelas padrão de engenharia. Empresas de médio porte se veem disputando o mesmo pool minúsculo de talentos com Google, Amazon e Microsoft. A maioria perde essa briga e parte pro plano B: treinar o time interno.

Só que o plano B tem um efeito colateral brutal. Engenheiros seniores de Java com 10 anos de estrada se sentem juniores de novo. Travam em tarefas que antes levavam minutos. O moral cai. Os melhores pedem demissão. Os ganhos teóricos de segurança evaporam diante de atrasos em projetos e turnover galopante.

Linux 7.0: a prova de que Rust faz sentido, só não onde você pensava

Enquanto o TIOBE pintava esse cenário de estagnação, o kernel Linux 7.0 saiu com suporte oficial ao Rust finalizado. E aqui mora a contradição que define toda essa discussão.

Devs de kernel são a elite absoluta da engenharia de sistemas. Escrevem drivers de hardware e interfaces de baixo nível onde cada byte importa e um kernel panic derruba infraestrutura global. Para eles, a curva de aprendizado brutal faz todo sentido. O custo de um bug em produção justifica qualquer atrito no desenvolvimento.

Agora responde com honestidade: o painel de RH interno da sua empresa precisa desse nível de rigor? A API REST que serve o app do cliente exige controle de memória no nível de um sistema operacional?

Na maioria esmagadora dos casos, a resposta é não. E insistir nisso não é boa engenharia, é desperdício deliberado de recursos.

Linus Torvalds e a variável que ninguém colocou na equação

O próprio Torvalds levantou um ponto durante o processo de lançamento do kernel 7.0 que merece atenção: ferramentas de IA podem, em breve, detectar bugs arquitetônicos complexos antes de qualquer revisor humano.

A provocação é direta. Se agentes autônomos eventualmente conseguirem escrever, verificar e sanitizar código C legado com precisão cirúrgica, a corrida desesperada por linguagens estruturalmente rígidas pode se tornar irrelevante. Não porque segurança de memória não importa, importa demais, mas porque o caminho para alcançá-la pode não passar por forçar uma linguagem nova goela abaixo de todo o ecossistema.

O pragmatismo já começou (e tem nome)

A solução que está ganhando tração real nas empresas é menos dramática e mais eficaz: isolar código C++ legado em sandboxes em vez de tentar reescrever milhões de linhas de lógica de negócios funcional.

Enquanto isso, Go continua dominando microsserviços cloud-native com uma curva de aprendizado incomparavelmente mais suave. C# e Java mantêm domínio absoluto no backend corporativo, blindados por décadas de ferramentas maduras, pools de talentos gigantescos e garbage collectors cada vez mais eficientes operando silenciosamente em segundo plano.

O mercado fez a correção que precisava fazer. O setor percebeu coletivamente que adotar a stack da Amazon não garante os resultados da Amazon, especialmente se você é um provedor de logística regional ou um banco de varejo tradicional.

Rust não morreu. O hype é que está morrendo.

Rust vai ocupar, e merece, um nicho sólido na engenharia de sistemas. Sistemas operacionais, dispositivos embarcados IoT, roteamento de rede de alto desempenho. Nesses contextos, a linguagem é imbatível.

O que está se dissipando é o sonho de que Rust seria a linguagem universal da web empresarial moderna. E talvez seja hora de perguntar: na corrida pela segurança de memória absoluta, ignoramos o fator mais imprevisível e mais importante de qualquer sistema?

As pessoas que escrevem o código.

Uma ferramenta que exige perfeição absoluta antes de permitir qualquer progresso não constrói uma fundação. Constrói uma gaiola. E devs presos em gaiolas não inovam, eles pedem demissão.