Como foi passar de Rust para Zig

Artigo original ↗ Discussão no Hacker News ↗

A tentativa de Zig de ser um “C moderno” recebe reações mistas de desenvolvedores vindos de Rust, que comparam sua gestão explícita de memória, o design centrado em allocators e os recursos poderosos de compile-time com as garantias de segurança mais fortes e a ergonomia de estilo funcional de Rust. Muitos veem Zig como atraente para domínios de baixo nível e críticos de desempenho, onde controle sobre alocação e layout de dados importa, mas questionam se isso vale abrir mão do borrow checker de Rust, de um sistema de tipos mais rico e de ferramentas mais maduras. O debate também toca o desconforto crescente com textos técnicos editados por IA e um sentimento mais amplo de que LLMs estão reduzindo o entusiasmo pessoal por aprender novas linguagens de programação, mesmo quando design de linguagem e conceitos continuam cruciais para usar essas ferramentas de forma eficaz.

Zig vs. Rust: Principais conclusões

  • Muitos veem Zig como moderno, rápido e “tipo C, mas mais agradável”, com forte interoperabilidade com C/C++ e compilação cruzada, mas claramente mais jovem e mais bruto que Rust.
  • Rust é apresentado como uma “linguagem imperativa com forte influência funcional”, bem adequada ao nicho de “C++ reimaginado”, com ferramentas e suporte de IDE muito mais maduros.
  • Vários comentadores enfatizam que Zig é intencionalmente mais baixo nível e mais explícito que Rust, sem alocação oculta nem fluxo de controle oculto; outros argumentam que Rust pode oferecer controle igualmente refinado, só que com mais segurança.

Estilo funcional vs. estilo imperativo

  • Os idioms funcionais de Rust (iterators, map/filter/flat_map, enums, pattern matching, tipos de erro monádicos) são elogiados por alguns como elegantes e expressivos, especialmente para desenho de APIs.
  • Outros acham cadeias longas de iterators ilegíveis e “desequilibradas” em comparação com loops simples, dizendo que entusiastas de Rust exageram os benefícios de legibilidade.
  • Em Zig, um estilo funcional é possível, mas muitas vezes parece pouco prático porque você precisa gerenciar explicitamente os allocators; transformações puras podem se tornar caras em memória ou pesadas em burocracia.
  • A discussão sobre “monads” surge principalmente em torno do uso disseminado de flat_map e combinators; alguns sentem que isso é uma escolha de estilo, não uma restrição rígida da linguagem.

Allocators, arenas e gerenciamento de memória

  • Grande subthread sobre a “obsessão com allocators” em Zig, Odin, Jai, etc.:
    • Pró: arenas e allocators customizados são cruciais em jogos, kernels, bancos de dados e workloads rígidos em tempo real ou por requisição/por frame; políticas explícitas de alocação codificam decisões importantes de desempenho.
    • Cético: a maior parte do software do mundo real não precisa de design centrado em allocators; APIs genéricas sobre allocator podem ser exagero; allocators gerais modernos (ou implementações melhores de malloc) muitas vezes bastam.
  • Vários observam que arenas podem simplificar o gerenciamento de tempo de vida (liberar em bloco) e reduzir o rastreamento manual de ponteiros, mas podem aumentar o uso de memória e complicar estruturas como hash maps.
  • A ausência de um allocator global em Zig força estratégias de alocação a serem explícitas (muitas vezes via parâmetros), o que alguns veem como uma vantagem e outros como ruído.

Recursos de compile-time: comptime de Zig vs. const de Rust

  • Rust busca que a avaliação em tempo de compilação se comporte identicamente ao runtime (mesma semântica de target), o que restringe o que é permitido (por exemplo, ponto flutuante limitado e traits em const).
  • O comptime de Zig é mais poderoso e geral, mas pode produzir resultados diferentes entre tempo de compilação e runtime, especialmente para ponto flutuante e diferenças de plataforma.
  • Alguns valorizam as garantias mais rígidas de Rust para builds reproduzíveis; outros preferem a flexibilidade de Zig e acham que seu comptime é mais eficaz na prática hoje.

Ferramentas e experiência do desenvolvedor

  • As ferramentas de Rust (cargo, integração com IDE, ecossistema) são geralmente vistas como muito à frente.
  • A linha de comando e a compilação cruzada de Zig são elogiadas, mas a falta de suporte robusto a IDE é apontada como um ponto de atrito inicial e marcante.
  • Alguns apreciam redescobrir um fluxo de trabalho “CLI-first” e arquivos grandes e autocontidos em Zig.

Hype de linguagem, LLMs e motivação

  • Vários comentadores expressam menos entusiasmo por novas linguagens na era dos LLMs, sentindo que o conhecimento detalhado de linguagem importa menos quando a IA escreve grande parte do código.
  • Outros argumentam que conceitos, abstrações e design de sistemas são mais importantes do que nunca, porque você precisa orientar e validar a saída dos LLMs.
  • Há uma irritação perceptível com “AI-isms” na prosa do artigo; alguns sugerem que escritores agora precisam evitar conscientemente esses trejeitos para parecerem autênticos.

Filosofia mais ampla de linguagens

  • Alguns argumentam que nunca pode existir um “verdadeiro sucessor de C” porque a falta de recursos de segurança do C é intencional para uso como “assembly de alto nível”; qualquer proteção muda a categoria.
  • Há divergência sobre se linguagens de sistemas (C, Rust, Zig) deveriam ser usadas para aplicações em geral; alguns dizem que apenas SO/código de baixo nível, enquanto outros apontam apps críticos de desempenho (BDs, servidores, jogos) como bons encaixes.
  • Zig é visto como atraente para desenvolvedores que ainda gostam de C e querem uma variante moderna e explícita; Rust atrai mais quem quer forte segurança e abstrações.