O caso pelo Rust no sistema base

Artigo original ↗ Discussão no Hacker News ↗

Desenvolvedores e usuários do FreeBSD estão avaliando se devem adotar Rust no “sistema base” do sistema operacional — o kernel central, a libc e os utilitários padrão enviados com cada instalação. Os defensores destacam a segurança de memória do Rust, o sistema de tipos mais forte e as ferramentas modernas como uma forma de reduzir vulnerabilidades e possibilitar componentes de sistema mais robustos, enquanto os críticos alertam para a complexidade adicional de build, o suporte fraco para algumas arquiteturas e o risco de fragmentar um projeto tradicionalmente conservador e centrado em C. Muitas vozes sugerem um uso gradual e seletivo de Rust e uma coordenação mais estreita com as ferramentas upstream do Rust, em vez de uma mudança completa.

Escopo: o que “sistema base” significa no FreeBSD

  • Inclui kernel, libc (fortemente ligada ao kernel), utilitários centrais, dtrace e compiladores necessários para construir o base.
  • Entregue e atualizado como uma única unidade coesa (patches binários), distinta de “ports” e pacotes de terceiros.
  • A cultura do projeto tende para um base enxuto; linguagens como Perl foram removidas; a cadeia de ferramentas LLVM agora é o principal “inchaço”.

Motivações para Rust no Sistema Base

  • Desejo de um alvo Rust estável no FreeBSD e melhor integração para ferramentas do sistema (por exemplo, jails, gerenciamento de ZFS).
  • Acesso a código Rust específico do FreeBSD por desenvolvedores centrais é visto como orientação valiosa.
  • Criação mais fácil de ISOs personalizadas que incluam utilitários de gerenciamento baseados em Rust.
  • Alguns querem que Rust substitua C++ no base e tire o OpenSSL dos ports, usando bibliotecas TLS em Rust para ferramentas como fetch.

Rust vs C/C++: segurança e recursos da linguagem

  • Garantias estáticas mais fortes sobre segurança de memória e data races por meio de ownership/borrowing e do borrow checker.
  • Moves destrutivos e tratamento claro de objetos “borrowed” versus “owned” evitam muitos bugs de use-after-free e de invalidação de iteradores que em C/C++ ficam para o runtime ou para comportamento indefinido.
  • Ferramentas modernas (Cargo), conceitos mais ricos de biblioteca padrão e padrões avançados de type/iterator/monadic foram elogiados; reconhece-se uma curva de aprendizado íngreme.
  • Há debate sobre o quanto isso realmente difere de RAII em C++, mas há consenso de que Rust torna muito mais difíceis os erros de tempo de vida e concorrência.

Preocupações com plataforma e cadeia de ferramentas

  • O suporte tier-1 do Rust é estreito; o FreeBSD suporta mais arquiteturas, embora essa lista esteja encolhendo.
  • Há dúvidas de que o FreeBSD tenha recursos ou interesse para levar os alvos FreeBSD ao tier-1 do Rust.
  • Sugestões: usar o frontend Rust do GCC ou compiladores que geram C (por exemplo, mrustc) para plataformas de longo cauda, mas a viabilidade é questionada.
  • Alguns argumentam que arquiteturas legadas que não conseguem acompanhar cadeias de ferramentas modernas já estão em “tempo emprestado”; outros veem os BSDs como o último bastião para esse hardware.

Problemas de build, tamanho e integração

  • Há preocupação de dobrar os tempos de build já pesados e centrados em LLVM se Rust entrar no base.
  • Discussão sobre adicionar uma etapa extra de build para componentes dependentes de Rust após buildworld e/ou desacoplar as toolchains do world.
  • Tensão entre manter o base minimalista e integrar Rust profundamente.

Segurança, confiabilidade e testes

  • Vários comentários associam 60–70% das vulnerabilidades sérias à insegurança de memória e veem Rust como um remédio parcial.
  • Outros destacam que a maioria dos ataques em larga escala ainda são questões “básicas” e que Rust não resolve todos os problemas de segurança.
  • Debate sobre se a escolha da linguagem ou a disciplina de testes/QA importa mais; vários defendem que as garantias da linguagem reduzem diretamente a carga de testes e certas classes de bugs.
  • Alguns temem que Rust no kernel/nas camadas baixas ainda ficará cheio de unsafe e adicionará complexidade, minando a simplicidade valorizada em núcleos de SO seguros.

Mocking, estratégia de testes e experiência do desenvolvedor

  • Exemplo: uma suíte de testes de um filesystem FUSE usando mocking pesado foi considerada praticamente inviável em C, mas administrável em C++/Rust.
  • Contra-argumento de que o mocking em si costuma ser uma estratégia de teste ruim, independentemente da linguagem.
  • Elogios gerais às ferramentas e à infraestrutura de testes do Rust, embora o mocking em Rust não seja universalmente amado.

Ecossistema, filosofia e impacto na comunidade

  • Comparações: FreeBSD/Go vistos como conservadores e estáveis; Linux/Rust como rápidos e flexíveis.
  • Alguns temem que Rust no base possa ser divisivo e desestabilizador, comparando-o a uma cisão no estilo “emacs vs vi”.
  • Outros veem a introdução seletiva (componentes não kernel, novos daemons) como um caminho razoável que não substituirá C imediatamente, mas ampliará as opções.