Rust em 2025: mirando o software fundacional

• Rust completa 10 anos neste ano e vem se consolidando como a principal linguagem para o desenvolvimento de software fundacional (Foundational) no futuro
• Software fundacional significa a camada que serve de base para tudo, como kernels de sistemas operacionais, plataformas de nuvem, dispositivos embarcados e ferramentas de CLI
• Rust reduziu a barreira de entrada ao oferecer desempenho e confiabilidade no nível de C/C++, ao mesmo tempo em que garante segurança de memória com seu sistema de tipos
• A missão do Rust não se limita apenas à camada de base: por meio de projetos como Dioxus, Tauri e Leptos, ele também vem influenciando o desenvolvimento de aplicações de níveis superiores
• Para o futuro, planeja investir principalmente em interoperabilidade entre linguagens, expansão do sistema de tipos e fortalecimento do ecossistema

---

A visão do Rust: software fundacional

• A visão central do Rust é tornar mais fácil escrever e manter software fundacional
  • Software fundacional inclui kernels de sistemas operacionais, infraestrutura de nuvem, dispositivos embarcados e ferramentas de CLI, que formam a base de todos os sistemas
  • Ele já está sendo adotado em vários lugares, como os kernels do Windows e do Linux, o mecanismo de busca do VSCode ripgrep, o Deno e o gerenciador de pacotes Python uv
• Nesse tipo de software, desempenho, confiabilidade e produtividade são igualmente cruciais
  • Se a base falha, toda a camada superior é afetada, então estabilidade é indispensável
  • Quedas de desempenho acabam limitando o desempenho das camadas acima, por isso é necessário minimizar overhead

Desempenho, confiabilidade e produtividade no software fundacional

• O software fundacional, como qualquer outro software, tem várias exigências, mas aqui cada uma delas se torna ainda mais importante
  • Confiabilidade é a prioridade máxima. Se a fundação quebra, tudo o que está sobre ela falha junto
  • Overhead de desempenho define o limite de desempenho das camadas superiores e, por isso, deve ser minimizado
• Tradicionalmente, havia duas opções para atender a esses requisitos
  • C/C++: oferecem grande liberdade, mas exigem um nível equivalente de perfeição
  • Linguagens de alto nível como Java e Go: exigem estilos especiais de programação para manter o desempenho, impondo restrições ao uso de abstrações e conveniências
• Rust muda esse cenário ao combinar abstrações de custo zero com um sistema de tipos que garante segurança de memória
• Assim, torna-se uma ferramenta que permite escrever código de alto nível com segurança, alcançando ao mesmo tempo desempenho de baixo nível e estabilidade de memória

Reduzir a barreira de entrada e ampliar a capacidade dos desenvolvedores

• Em apresentações sobre Rust, o sistema de tipos e as verificações estáticas costumam ser comparados a "espinafre": algo bom para você, mas que ninguém quer consumir
• Na prática, porém, o sistema de tipos é uma ferramenta extremamente poderosa para desenvolvedores
• Iniciantes podem aprender, por meio dele, a estruturar software de forma bem-sucedida
• Especialistas conseguem detectar mais rapidamente erros em suas próprias estruturas e designs

• A frase de Yehuda Katz, "As abstrações que construo em estado de foco ajudam o meu eu cansado do futuro", resume bem essa ideia

Além do software fundacional

• Mesmo que a missão do Rust esteja focada em software fundacional, isso não significa ignorar outras áreas
• Projetos como Dioxus, Tauri e Leptos estão expandindo o uso de Rust também para aplicações de nível mais alto, como GUIs e páginas web
• O principal ponto forte do Rust continua sendo, por natureza, o foco em software fundacional, mas essas iniciativas também não devem ser ignoradas

Metas ambiciosas e crescimento

• Como o software fundacional exige controle detalhado de baixo nível, em geral há a tendência de considerar acessibilidade e ergonomia como menos importantes
• Mas, justamente por haver esse nível de controle necessário, a usabilidade se torna ainda mais importante
• Se o desenvolvedor puder se concentrar apenas no que realmente importa, a produtividade aumenta bastante

• Projetos que impulsionam aplicações de alto nível em Rust também criam oportunidades para tornar a programação em Rust mais conveniente
• Essas melhorias acabam sendo refletidas integralmente também no desenvolvimento de software fundacional
• O ponto central é aumentar a usabilidade sem perder controle e confiabilidade

A importância do suporte à stack completa

• Outro motivo para tornar o desenvolvimento de aplicações de alto nível mais agradável em Rust é a possibilidade de construir a stack completa com uma única tecnologia
• Desenvolvedores que inicialmente planejavam usar Rust apenas em partes específicas, como serviços de data plane, vêm cada vez mais expandindo seu uso para toda a área
• Isso acontece porque Rust tem alta produtividade e permite compartilhar bibliotecas e código em uma única linguagem
• Em essência, código simples continua simples, não importa em qual linguagem seja escrito

A experiência de aprofundamento iterativo (Iterative Deepening)

• Idealmente, a primeira experiência de quem usa Rust deveria ser simples, e, à medida que o projeto avança, deveria ser possível expandir gradualmente mais controle de forma localizada
• Isso parece simples, mas na prática é um desafio muito difícil
• Muitos projetos fracassam por terem uma barreira de entrada alta para iniciantes ou por exigirem muito conhecimento para aprender níveis mais avançados de controle
• Rust nem sempre acerta, mas continua trabalhando de forma constante para melhorar isso

Planos para o futuro

• Este texto é o primeiro desta série e, ao longo de mais quatro artigos, pretende apresentar as áreas de investimento necessárias para tornar o Rust mais adequado ao software fundacional
  • Interoperabilidade entre linguagens (smooth language interop) e extensibilidade (extensibility)
  • Clareza de propósito (clarity of purpose) por meio do sistema de tipos
  • Fortalecimento do ecossistema: melhores diretrizes, ferramentas e uso da Rust Foundation
  • No último artigo, será discutida a operação da organização open source do Rust, com foco em como tornar contribuição e manutenção atividades o mais acessíveis e agradáveis possível

[yeorinhieut]

Mesmo que Rust pareça até legal, acho que é a única linguagem que me dá preguiça por causa do fandom tóxico (?) em volta dela.

[aer0700]

Seria ótimo se C ou C++ tivessem um gerenciador de pacotes padrão. Sempre penso nisso quando vejo o Cargo.

[cosine20]

Mas espinafre é tão gostoso....

[t7vonn]

Hoje em dia, não há lugar onde Rust não seja usado.

[lostid]

Trabalho em uma empresa relativamente grande, mas não existe nenhuma área onde Rust seja usado. Por favor, não tentem distorcer a realidade.

[t7vonn]

Não arrume briga.

[bobross0]

Credo;;;;;;;

[crawler]

Não venha arrumar confusão, viu? 😅

[shakespeares]

Caramba ;;

[qwas5544]

Nossa...;;;

[lostid]

Deixando todo o resto de lado, ultimamente esses fanáticos por Rust estão me deixando doente de tanta raiva. Offline, é uma minoria dentro da minoria, mas online é quase um ISIS... Ah, sei lá, queria que se juntassem num canto e ficassem brincando só entre eles...

[ifmkl]

Muitas vezes, para quem paga de "rustacean", dá até para duvidar se a própria pessoa realmente usa direito.

[skageektp]

Mesmo assim... vocês gostam de Rust, né?
Podem até odiar os fanáticos por Rust, mas por favor amem Rust ;_;

[taeunlee99]

Mesmo apanhando feio por causa do FFmpeg, ficam dizendo que todo o código tem que ser escrito em Rust e coisas do tipo.

[GN⁺]

Comentários do Hacker News

• Ao discutir software essencial, o ponto mais decepcionante no Rust seria a ABI. Para criar um OS em Rust e oferecer serviços ricos, os aplicativos precisam continuar funcionando após atualizações do sistema sem exigir recompilação das bibliotecas. O Windows resolve isso com COM, a Apple resolveu por um tempo com o dynamic dispatch do ObjC (e agora com a ABI do Swift), e o Android com JVM e bytecode. O Rust, na prática, só oferece suporte a extern "C", o que limita o uso de bibliotecas dinâmicas. Fornecer uma ABI sem uma camada de VM (JVM, .NET) é extremamente difícil, e como isso exige nunca mais mudar detalhes de implementação já definidos, faz sentido que a prioridade seja baixa. Na prática, só Swift e COM parecem ter tido sucesso com esse modelo. Se o Rust adotasse uma ABI completa, ficaria perto de uma linguagem quase perfeita. (Gerenciar dependências em formato binário também reduziria muito o tempo de compilação)

  • Explica-se que o motivo de o Rust querer introduzir apenas estabilidade de ABI opcional por padrão é a busca por zero-cost abstractions. Uma ABI estável traz perda de desempenho, como o caso do C++ mostra (explicação sobre ABI de C++). Para carregar plugins Rust dinamicamente entre si com dlopen, existem ferramentas como stabby e abi_stable, que funcionam bem. Para interoperabilidade mais geral entre linguagens, o crABI (proposta do crABI) pode ser uma alternativa futura. Ainda assim, isso não é algo que o Rust possa resolver sozinho; também exige apoio e cooperação de outras linguagens e de várias comunidades, como as distribuições Linux. Também se menciona que, como Rust é uma linguagem em que a forma de I/O e de alocação de memória é escolhida explicitamente, talvez uma estrutura como a do Swift, que resolve tudo com bibliotecas compartilhadas, não se encaixe tão bem.
  • Estão praticamente tentando resolver o mesmo problema com Wasm Components. Se o WebAssembly é um formato de instrução portável, WebAssembly Components é um formato portável de execução/linkagem. Não é tão simples quanto repr(wasm)/extern "wasm", mas com wit-bindgen ou o alvo wasm32-wasip2 dá para usar sem muita dificuldade. Vídeo de introdução ao Wasm Components
  • Expressa-se dúvida sobre isso ser realmente necessário. Seria mais conveniente passar mais tipos de “coisas” (slices, trait objects etc.) pela interface, mas na prática tudo que é necessário pode ser feito apenas com a ABI extern "C". E também já houve propostas para expandir a ABI extern para mais tipos
  • Houve uma palestra sobre esse tema em uma conferência Rust, fortemente inspirada na abordagem do Swift. A expectativa é que isso avance nessa direção no futuro
  • Na prática, isso já existe. Chama-se justamente C

• Gosta muito de Rust, mas gostaria que alguns problemas crônicos e irritantes recebessem mais atenção

  • 1. Existe o problema de self-referencing structs. Por exemplo, mesmo querendo colocar o arquivo-fonte e a AST parseada na mesma struct, hoje isso não é simples. Seria bom ter algo como offset references
  • 2. orphan rule (regra de trait órfã). Entende-se o motivo, mas ainda assim continua sendo uma regra irritante. Dá para contornar com recursos novos (às vezes exigindo 2 ou 3 camadas de wrapper!), mas fica a dúvida se isso realmente precisa ser assim
  • 3. Para conseguir tempos de compilação razoáveis, é preciso dividir o projeto em muitos crates pequenos. Entende-se o motivo, mas o resultado não é bom. Um crate é tratado como uma única unidade de compilação, e isso acontece porque dependências cíclicas são permitidas. Mas a maior parte do código, na prática, não tem dependências cíclicas, então seria bom ter isso como opt-in ou então dividir automaticamente itens/arquivos dentro do crate em unidades de compilação conforme o grafo de dependências
  • Foram citadas apenas as coisas que vieram à cabeça, mas provavelmente há mais. Ainda assim, Rust é a melhor linguagem da vida dessa pessoa, mesmo sendo uma crítica construtiva
    • Aponta-se que Rust não permite dependências cíclicas entre crates, mas permite entre módulos dentro de um crate. A maior parte do código provavelmente não tem ciclos, mas por exemplo qualquer módulo com um submódulo de teste já acaba entrando nessa regra. Para separar os testes corretamente, seria preciso definir todas as funções de teste na raiz do crate, o que é ineficiente na prática
    • Concorda-se totalmente com os itens 1 e 2. Adiciona-se como item 4 o desejo por partial self borrows (um recurso para métodos pegarem emprestado apenas parte de uma struct). Quanto ao item 3, antes seria melhor ter suporte mais robusto, como a possibilidade de publicar vários crates de uma vez
    • Sobre a orphan rule, pede-se mais explicação: a ideia é que o Rust adote outra alternativa melhor, ou apenas que existam recursos capazes de substituir isso?
    • Concorda-se plenamente com a orphan rule. Seria bom poder desativá-la em application crates, ou relaxar a regra quando houver higiene suficiente garantida por proc macro etc.

• Ao refletir sobre a expressão “Smooth, iterative deepening”, considera-se que o Rust dá importância demais à compatibilidade entre linguagens, o que pode acabar só aumentando a complexidade e prejudicando a segurança. Nesses casos, seria mais útil substituir as partes mais fundamentais do sistema, como a libc. O Go quase não faz chamadas cross-language. O Google fortaleceu a base ao desenvolver internamente suas bibliotecas essenciais, mas no Rust há várias versões concorrentes de bibliotecas fundamentais, e muitas delas estão incompletas

  • Afirma-se que, nos últimos 20 anos, uma das tarefas centrais da ciência da computação tem sido permitir que vários programas se comuniquem eficientemente dentro da mesma máquina. A maioria tenta contornar a base de DLLs da Microsoft com código-fonte e estado, ou então brokers de requisição de objetos como o CORBA, que não conseguiram se firmar. O mesmo vale para RPC ao estilo qnx. Por isso, continua-se repetindo tentativas de forçar coisas que não se encaixam a funcionar juntas
  • Na prática, tudo também poderia ser resolvido com sockets, mas como sockets são fluxos brutos de bytes, eles são uma abstração errada — ainda assim acabam sendo usados por serem convenientes
    • Pelo que se entende, o texto da postagem não está propondo um substituto real para shared libraries cross-language como DLL/COM/Wasm components, e sim respondendo à necessidade prática de migrar C++ gradualmente para Rust. Para melhorar a segurança de memória do sistema como um todo, a grande questão é “o que fazer com os programas existentes”, e o nível atual de interoperabilidade entre Rust e C++ é insuficiente. Se as duas linguagens pudessem cooperar bem no nível de código-fonte, aumentaria bastante a chance real de o Rust substituir boa parte do espaço hoje ocupado pelo C++
    • Às vezes parece que, desde que sockets e protocolos batam, isso já vira quase a melhor abstração cross-language possível. Então fica a curiosidade: qual seria, de fato, a abstração ideal de chamadas cross-language?

• Destaca-se que “evitar alocação, evitar acionar o GC” não está de acordo com conceitos modernos de GC e JIT. GCs modernos muitas vezes quase não têm latency stop-the-world, e o uso total de CPU do GC depende principalmente da proporção entre resident set e tamanho do heap. JIT tem mais oportunidades de otimização do que AOT, e pode explorá-las de forma mais agressiva (graças a otimização especulativa). O que realmente importa são atraso de inicialização/aquecimento, overhead de memória e desempenho médio, não o pior caso degradado. Além disso, não é garantido que gerenciamento manual de memória seja mais eficiente, e mesmo que o uso real de RAM triplique, a diferença de custo pode ser zero. Também se recomenda esta apresentação da ISMM, que trata bem do tema

  • Pergunta-se mais concretamente o que significa dizer que o JIT vê mais oportunidades de otimização. No fim, JIT é apenas um complemento ao AOT
  • Pergunta-se a que implementação exatamente se refere essa ideia de “GC moderno” aqui

• Considera-se que os comentários sinalizados e a discussão captaram bem os pontos centrais. “Vamos criar um padrão de linguagem com especificação oficial”, “precisamos de várias implementações” etc. são questões importantes na prática. Em especial, @infogulch apontou bem que, para uma linguagem se tornar base da indústria, uma especificação formal é essencial (comentário de referência)

  • Além de não estar claro por que o comentário foi sinalizado, dá-se um exemplo espirituoso de que, na prática, muitas linguagens se tornaram base industrial sem especificação padrão nem múltiplas implementações. Ruby até tem um padrão ISO antigo, mas limitado àquela versão, e Python na prática usa a própria implementação como padrão. O mesmo vale para Rust, e do ponto de vista da maioria dos usuários isso não é motivo para trocar de linguagem
  • Ao pesquisar sobre “padrão oficial da linguagem”, encontrou-se o documento de referência rust-lang/reference. O projeto Rust leva bem a sério a especificação da linguagem. O recente post sobre a visão da especificação explica em detalhes o progresso. O trabalho de especificação é enorme e difícil, mas continua ativo a ponto de PRs serem mesclados na branch master até nos fins de semana
  • Espera-se que o ponto sobre precisar de várias implementações já tenha sido ajudado pelo desenvolvimento oficial de compiladores alternativos de Rust como o gccrs
  • Há uma visão cética de que tanto LLM quanto Rust, no fundo, apenas satisfazem parte das pessoas e trazem um pequeno ganho de produtividade. Ainda assim, não se concorda com a postura de ampliar a influência sem responsabilidade dentro da comunidade
  • Pede-se que expliquem melhor o que exatamente significa “published language standard” e qual seria sua utilidade prática
  • Não há insatisfação com o Rust em si, mas sim com a atitude de alguns usuários que não entendem o quão importante é uma especificação formal. Todo sistema computacional tem sua longevidade e confiabilidade determinadas pelo grau de formalidade com que sua especificação é tratada. Sem uma especificação clara, tudo passa a depender totalmente de “qual implementação por acaso funcionou com determinada entrada”, e construir sistemas sobre uma base tão frágil é arriscado. Em computação, a especificação é o sistema em si (a implementação é apenas uma otimização secundária)

• As pessoas frequentemente questionam se o Rust realmente precisa ter especificação, e isso é visto como prova de que há engenharia de menos em engenharia de software

  • Considera-se que engenharia de software não é engenharia de verdade. Não é preciso construir três vezes uma ponte ou um arranha-céu para acertar, mas no software isso acaba sendo até uma boa abordagem

• Sobre um comentário dizendo que Rust é “uma linguagem usada apenas por quem quer parecer programador”, alguém responde que, na verdade, ama programar e Rust foi um choque renovador. Não quer de jeito nenhum voltar ao passado extremamente doloroso do C++. E não considera tão importante ter padrão de linguagem (doação da especificação Ferrocene) ou várias implementações. Python e Java também funcionam bem dependendo de uma implementação central. O C++ tentou dar suporte a vários compiladores e acabou apenas ampliando problemas complexos por plataforma. Não fica claro o que exatamente seria a “bagunça” do cargo, e a experiência com C++ parecia muito pior

  • Pergunta-se especificamente o que há de problemático no cargo
  • Acrescenta-se a dúvida se padrões de linguagem/ferramentas e diversidade de implementações são realmente tão importantes, se não seria cedo demais para isso, e se o Rust teria sido tão bem-sucedido quanto foi caso tivesse gasto energia com isso desde o começo. O artigo parece não defender uma substituição total de tudo, mas sim destacar suporte e adequação para um alvo de uso específico
  • Considera-se o cargo atualmente o melhor package manager entre as grandes linguagens do mundo. Ele aprendeu muito bem com as falhas dos package managers anteriores e hoje é extremamente refinado e maduro como infraestrutura. Pode até precisar de pequenas melhorias, como namespaces e fully repeatable builds, mas praticamente seria impossível transplantar o cargo atual para outra linguagem. Pouquíssimas linguagens têm uma infraestrutura desse nível