Acho que C++ ainda é uma plataforma de programação desejável em comparação com Rust

Artigo original ↗ Discussão no Hacker News ↗

Defensores de C++ e Rust discutem se C++ ainda é uma escolha preferível para novos trabalhos de sistemas, equilibrando a maturidade de C++, o desempenho, o ecossistema e a base maior de profissionais contra as garantias de segurança mais fortes de Rust e sua ferramenta mais coerente. Muitos argumentam que equipes disciplinadas de C/C++ podem evitar a maioria dos bugs de memória, mas isso vem com um alto custo de produtividade e ainda deixa espaço para vulnerabilidades sutis, enquanto o borrow checker de Rust, os enums/pattern matching, o tratamento de erros e o fluxo de trabalho baseado em Cargo capturam classes inteiras de problemas por construção. Outros apontam lacunas e trade-offs em Rust — como cenários embarcados e de bibliotecas compartilhadas, tamanho de binário, qualidade do ecossistema e complexidade de async — concluindo que Rust está corroendo gradualmente o domínio de C++, mas ainda não o substituiu completamente.

Adoção da linguagem e casos de uso

  • Muitos comentaristas com longa experiência em C++ agora recorrem por padrão a Rust para trabalhos novos do zero e projetos pessoais, citando produtividade e segurança; eles ainda usam C++ quando exigido por código legado, bibliotecas existentes ou política da empresa.
  • Alguns permanecem firmemente com C ou C++ (incluindo “C++ moderno”), argumentando que, com disciplina suficiente, ferramentas e testes, bugs de memória são raros o bastante e que os benefícios de Rust não são convincentes para eles.
  • Há consenso de que C++ “não vai a lugar nenhum” devido à sua enorme base instalada, às toolchains existentes e à cobertura em sistemas embarcados/dispositivos.

Ferramentas, sistemas de build e ecossistemas

  • O Cargo do Rust mais o crates.io são amplamente elogiados como uma grande vantagem: um sistema de build padrão, gerenciamento de dependências fácil, cross-compilação simples.
  • Outros criticam o crates.io como “parecido com npm”: muitos crates hobby 0.x, longas cadeias de dependências, várias versões em um único binário, falta de namespaces e moderação; algumas grandes organizações fazem vendoring e gerenciam dependências internamente.
  • A fragmentação das ferramentas de build de C++ (CMake, Bazel, sistemas personalizados) é vista como uma grande dor de cabeça, embora alguns argumentem que sistemas maduros de build em C++ podem ser superiores ao Cargo em certos fluxos de trabalho empresariais.

Segurança vs. “disciplina”

  • Um grupo afirma que equipes disciplinadas de C/C++ com sanitizers, fuzzing e práticas rígidas conseguem evitar a maioria dos crashes de memória; eles minimizam a segurança de Rust como supervalorizada.
  • Outros contrapõem que até projetos elite em C/C++ (kernels, navegadores, bancos de dados) ainda lançam vulnerabilidades de memória, e que corrupção silenciosa de memória é muito pior do que segfaults ocasionais.
  • A segurança é enquadrada como “preservar invariantes”, com o sistema de tipos de Rust e o borrow checking reduzindo classes inteiras de bugs por construção.

Desempenho e otimização

  • Alguns argumentam que o comportamento definido de overflow e as verificações de limites do Rust impõem overhead não trivial, justificando o comportamento indefinido do C++ pela máxima liberdade de otimização.
  • Outros respondem que:
    • Rust oferece primitivas aritméticas checked/wrapping/saturating para controle explícito.
    • Compiladores muitas vezes conseguem eliminar verificações de limites.
    • O overhead típico é pequeno em comparação com o custo de engenharia de UB e bugs de memória.
  • O Rust inseguro é enfatizado como uma “saída de emergência” direcionada, não como um abandono da segurança.

Recursos da linguagem e ergonomia

  • Rust recebe elogios por: enums/ADTs expressivos e pattern matching, tratamento de erros baseado em Result/Option, concorrência baseada em Send/Sync, mensagens de erro do compilador mais claras, linting e formatação embutidos, e ferramentas consistentes.
  • C++ recebe crédito por constexpr/const generics mais ricos, placement new, controle de alocadores, SIMD e um ecossistema de bibliotecas mais profundo e testado em batalha.
  • Tentativas de definir um “subconjunto seguro de C++ moderno” são vistas por alguns como inerentemente limitadas e menos práticas do que o subconjunto seguro explicitamente definido de Rust.

Tamanho do binário, linking e embedded

  • O padrão do Rust de linkar estaticamente sua biblioteca padrão pode gerar binários consideravelmente maiores do que C++ com bibliotecas compartilhadas, o que importa em sistemas embarcados ou de classe appliance com armazenamento restrito.
  • Técnicas como LTO, perfis otimizados para tamanho e no_std podem reduzir binários Rust, mas alguns consideram bibliotecas compartilhadas de C/C++ ainda mais eficientes em espaço para sistemas com vários binários.