Absolutistas da segurança de memória
A segurança de memória em programação de sistemas está no centro de um debate acalorado entre defensores das garantias em tempo de compilação do Rust e proponentes do Fil-C e de abordagens semelhantes com verificação em runtime para código legado em C/C++. Os comentários ponderam trade-offs entre modelos de segurança mais rígidos, sobrecarga de desempenho, quebra do ecossistema e ergonomia para desenvolvedores, observando que Rust é “majoritariamente seguro”, mas ainda depende de `unsafe` e FFI, enquanto Fil-C pode fortalecer bases de código existentes ao custo de velocidade. Muitos argumentam que a escolha da linguagem deve ser guiada por objetivos práticos de segurança e confiabilidade, e não por “guerras de linguagem” tribais, e que ferramentas como verificação formal e model checking podem importar tanto quanto a própria linguagem.
Segurança de memória como objetivo e seus limites
- Muitos argumentam que a segurança de memória deveria ser uma expectativa padrão, especialmente para software amplamente usado e qualquer coisa que lide com entrada não confiável (codecs, TLS, navegadores, sistemas operacionais).
- Outros observam que incidentes do mundo real são frequentemente causados mais por engenharia social, ataques à cadeia de suprimentos, bugs lógicos e problemas de configuração do que por corrupção de memória.
- Vários comentários enfatizam: segurança de memória é necessária, mas está longe de ser suficiente; outras classes de bugs (por exemplo, falhas lógicas/de design no estilo Log4Shell) permanecem.
Rust, Fil-C/Zig, linguagens com GC
- Rust é elogiado por combinar alto desempenho, sistema de tipos forte, modelo de ownership e boa toolchain; muitos dizem que seu valor vai muito além de “C++ mas seguro”.
- Fil-C é visto como atraente para adicionar segurança retroativamente ao C/C++ existente com verificações fortes em runtime, ao custo de desempenho e de crashes em vez de rejeições em tempo de compilação.
- Alguns argumentam que Fil-C pode ser estritamente “mais seguro” (sem saídas de escape), enquanto Rust e linguagens com GC têm bordas
unsafe/FFI; outros contra-argumentam que essa é uma distinção teórica se o unsafe for raro e bem contido. - Zig e C são preferidos por alguns pela expressividade em nível de ponteiro e pelo controle de baixo nível, apesar dos riscos reconhecidos.
Segurança em tempo de compilação vs. runtime
- As garantias de Rust em tempo de compilação são valorizadas por confiabilidade e menos depuração; esquemas apenas em runtime são vistos como transformar UB em crashes, o que é melhor, mas ainda doloroso.
- Outros priorizam “pegar em qualquer lugar” em vez de “pegar em tempo de compilação”, e aceitam verificações em runtime, fat pointers ou mecanismos no estilo Fil-C.
Legado em C/C++ e alternativas
- Grandes ecossistemas legados (kernels, toolchains, pilhas de GUI, APIs de GPU) tornam irrealista “reescrever tudo em Rust/GC”, motivando Fil-C e abordagens semelhantes.
- Alguns lamentam a recusa histórica de C/C++ em padronizar construções mais seguras (por exemplo, slices/spans com checagens de limites) apesar de décadas de experiência com linguagens seguras para memória.
Ferramentas de segurança, SO/hardware e métodos formais
- Model checking, análise estática e verificação formal (CBMC, Kani, WUFFS, compiladores/SOs verificados) são apresentados como complementares ou superiores a soluções apenas de linguagem.
- Problemas de hardware como rowhammer e bit flips (mitigados, mas não eliminados por ECC) mostram que “linguagem segura para memória” ≠ “memória fisicamente segura”.
Guerras de linguagem e cultura
- Muitos estão frustrados com o tribalismo entre Rust e Fil-C/Zig e com o enquadramento ideológico (“woke vs anti-woke”, evangelismo moralista).
- Vários pedem discussões pragmáticas, específicas de domínio, sobre trade-offs em vez de posições absolutistas de “uma linguagem verdadeira”.