Comprometendo-se com Rust para Código de Kernel

Artigo original ↗ Discussão no Hacker News ↗

A decisão do Linux de permitir Rust no desenvolvimento do kernel está gerando debate sobre se ele pode substituir com segurança e eficiência parte do código C de longa data, especialmente em drivers onde bugs de segurança de memória são comuns. Defensores destacam o modelo de ownership de Rust, as fortes verificações estáticas e os recursos no_std como ferramentas poderosas para uma programação de sistemas mais segura sem sacrificar desempenho, enquanto críticos apontam tempos de compilação mais lentos, complexidades em torno de código `unsafe` e preocupações com dependências de toolchain em LLVM e C++. Alternativas como Zig são mencionadas como filosoficamente mais próximas da “cultura C”, mas a relativa maturidade de Rust e seu uso já em produção em sistemas de baixo nível o tornam o principal candidato para adoção incremental no kernel.

Experiências de Migração de C→Rust

  • Quem migra relata que Rust força uma reflexão mais profunda sobre propriedade de dados, tempos de vida e padrões de “múltiplos leitores, um escritor”.
  • Essa mudança melhora o design mesmo quando se escreve C depois.
  • O tratamento de erros com Result/Option e match, testes inline e ferramentas de documentação são vistos como grandes ganhos de produtividade.
  • Vários afirmam que bases de código em Rust são significativamente mais concisas e parecem menos frágeis do que seus equivalentes em C.

Dados Dinâmicos e Manipulação de JSON

  • Alguns dizem que Rust torna tarefas altamente dinâmicas (por exemplo, esquemas JSON em tempo de execução, tabelas de banco de dados desconhecidas) “ligeiramente mais difíceis” do que linguagens dinâmicas.
  • Outros argumentam que isso é principalmente verbosidade extra, não uma limitação real, e apontam para crates existentes que fazem validação de esquemas JSON em tempo de execução.

Desempenho de Compilação

  • Reclamações: os tempos de compilação de Rust são “horríveis” em comparação com C e podem desestimular seu uso.
  • Contrapontos:
    • Para projetos de porte moderado, compilações limpas são concluídas em poucos minutos em laptops típicos.
    • Em comparação com C++, Rust costuma ser tão rápido quanto ou mais rápido para compilar quando os recursos são comparáveis.
    • Árvores de dependências pesadas e traits/macros prejudicam mais os tempos de compilação; Rust no kernel (no_std, poucas dependências) deve se sair melhor.
  • Benchmarks que comparam Rust e os coreutils em C mostram tempos de compilação dentro de um fator de cerca de 2×, dependendo do que é contado como trabalho de configuração.
  • Argumenta-se que a monomorfização por si só não é a principal culpada; seria necessário um design de linguagem fundamentalmente diferente para ganhos dramáticos.

Rust no Kernel e em Programação de Sistemas

  • Forte entusiasmo: a segurança de memória de Rust é vista como crítica para drivers, onde bugs de concorrência e padrões inseguros são generalizados.
  • Há evidências citadas de que bugs de segurança de memória no kernel são introduzidos mais rápido do que são corrigidos; Rust é proposto como uma mitigação estrutural.
  • Céticos:
    • Questionam a adequação de Rust para bare metal e sistemas de latência ultrabaixa, e não gostam da dependência do LLVM baseado em C++.
    • Alguns preferem Zig por estar culturalmente mais próximo de C e por ser mais hostil a grandes dependências de toolchain, mas reconhecem que Zig ainda não está estável o suficiente.
    • Uma tentativa em trading de baixa latência em Rust relata que os últimos 20% críticos para desempenho foram extremamente difíceis em Rust seguro; unsafe pareceu mais perigoso do que C.
  • Defensores respondem que:
    • A maior parte do trabalho de baixo nível pode ser isolada em pequenos trechos unsafe, com o restante se beneficiando da segurança.
    • Rust pode operar em níveis de abstração semelhantes aos de C (especialmente com no_std), ao mesmo tempo em que permite abstrações de alto nível e de custo zero quando apropriado.

Toolchains e LLVM/GCC

  • O kernel é cada vez mais construído com Clang; ainda existem bugs, mas a concorrência entre toolchains é vista como benéfica.
  • Alguns reclamam que o LLVM é difícil de compilar sem GCC/binutils/glibc; outros argumentam que isso é uma preocupação de nicho e observam que o GCC também depende de C++.