Voltando para Zig — Zig → Rust → Zig

• Zig começou como uma linguagem de baixo nível para reduzir as inconveniências do C e voltou a merecer atenção por sua filosofia de alocação explícita de memória e ausência de fluxo de controle oculto
• Rust foi uma alternativa prática para escapar das mudanças frequentes do Zig e de seu ecossistema imaturo, mas acabou mostrando limitações em pontos como FFI, compilação cruzada e alocações ocultas
• A decisão de voltar para Zig foi influenciada não só por razões técnicas, mas também pela perda de confiança no projeto Rust em torno de governança e da política sobre código gerado por LLM
• Em 2026, Zig continua instável e o Zig 0.17.0 deve quebrar o sistema de build, mas a sensação da linguagem não é muito diferente da de 2020 e a experiência de gerenciamento de pacotes melhorou
• Em vez de oferecer segurança de memória em tempo de compilação no estilo Rust, Zig escolhe um equilíbrio entre simplicidade e segurança em tempo de execução com ReleaseSafe, testes, fuzzing e uma filosofia baseada em assertions

---

O ponto de partida que me atraiu para Zig

• Conheci Zig pela primeira vez em 2020, e na época ele parecia uma pequena linguagem nova com execução de código em tempo de compilação e abstrações simples
• Aprender C era bom pela sensação de controlar o computador diretamente, mas as abstrações antigas e as ferramentas limitadas eram incômodas
• Mesmo sendo novo e instável, Zig prometia ser uma linguagem substituta para C, e a ideia de aprender “a próxima linguagem” era atraente
• Software Should Be Perfect, de Andrew Kelley, ajudou a formar meu critério para avaliar linguagens de programação e software
  • alocação explícita de memória com possibilidade de falha
  • ausência de fluxo de controle oculto
  • reutilização universal
• Fazendo linguagens de programação de brinquedo, ferramentas de literate programming e servidores web em Zig, tive a sensação de estar usando uma linguagem mais confortável que C, mas com menos armadilhas

Por que mudei para Rust

• Zig quebrava código com frequência, e como eu era estudante, não tinha tempo para continuar ajustando projetos às versões mais novas da linguagem
• Na época não existia anyzig, então não era fácil lidar com várias versões de Zig no mesmo sistema
• Às vezes eu voltava a um projeto depois de alguns meses e precisava fazer uma grande refatoração que eu nem entendia direito só para fazê-lo funcionar de novo
• O ecossistema também ainda era pequeno
  • como programador iniciante, eu não tinha capacidade de implementar sozinho tudo de que precisava
  • havia poucas bibliotecas e exemplos
  • a biblioteca padrão continuava mudando
  • até a documentação básica era instável
• Rust já estava estabilizado havia anos e tinha um ecossistema forte
• Aprender Rust foi difícil, mas depois de dominá-lo o código funcionava de forma estável, e essa estabilidade era importante
• Era uma linguagem rápida e de baixo nível, com a expressividade de que eu precisava, e reduzia o custo da instabilidade que eu enfrentava em Zig
• Rust também ajudou a formar um modelo mental de memória útil até ao usar linguagens com menos verificações embutidas
• Em código sem panic, era possível escrever código reutilizável sem fluxo de controle oculto nem garbage collector
• Ainda assim, Rust tinha aspectos que ocultavam alocação de memória e dificultavam o trabalho com C

As insatisfações que me fizeram olhar para Zig de novo

• Rust não era a linguagem perfeita para criar os programas reutilizáveis que eu queria
  • FFI é difícil
  • compilação cruzada é trabalhosa
  • alocações de memória ocultas, tratadas como se não pudessem falhar, são um peso
  • por estar preso ao LLVM, pode levar muito tempo ou até ser impossível suportar tantos alvos quanto C
• A governança também continuava sendo um ponto desconfortável
  • a Rust Foundation tem várias grandes empresas entre seus foundation members
  • se as maiores empresas do mundo fornecem centenas de milhares de dólares por ano, isso pode influenciar a direção de desenvolvimento do Rust
• Também foi chocante ver mais projetos de código aberto passando a aceitar código gerado por LLM
• Em vários projetos, mantenedores e usuários passaram a escrever ou exigir políticas sobre LLM
• Zig proibiu completamente LLMs no projeto
• Rust fez uma pesquisa e o sentimento geral da comunidade era anti-LLM, mas não criou imediatamente uma política oficial
• A proposta de política do Rust incluía, nos comentários do PR, uma cláusula que proibia mencionar os seguintes temas
  • impactos sociais e econômicos de longo prazo dos LLMs
  • impacto ambiental dos LLMs
  • status de direitos autorais das saídas de LLM
  • julgamentos morais sobre usuários de LLM
• Essa cláusula foi removida após reação contrária, mas o simples fato de ela ter existido já reduziu minha confiança no projeto Rust
• A política em si parecia aceitável na maior parte, por restringir LLMs e reduzir slop
• Essa experiência foi o que me levou a olhar para Zig novamente com seriedade depois de alguns anos

Zig em 2026

• Zig continua instável
• Tentei começar com um exemplo de Zig 0.16.0 encontrado na web, mas ele já estava desatualizado
• Para trabalhar de forma produtiva em Zig, o melhor é manter uma cópia do código-fonte da biblioteca padrão por perto e se familiarizar com ela
• O Zig 0.17.0 deve ser lançado em breve e deve quebrar o sistema de build de todos os projetos
• Os mantenedores estão tentando avançar rumo à estabilização, e esse tipo de quebra faz parte do processo
• Felizmente, a linguagem em si não mudou tanto desde 2020
  • a maior parte da minha intuição ainda funcionava
  • partes da biblioteca foram retrabalhadas, mas o código continuava fácil de ler
  • acredito que o código Zig atual ainda será reconhecível daqui a 6 anos
• Agora Zig tem um gerenciador de pacotes
  • lembro que antes se usava git submodule para gerenciar dependências
  • a ferramenta embutida é muito melhor
  • os projetos podem definir dependências com git e tarball
  • fazer vendoring funciona de forma fácil
• O ecossistema ainda não é enorme, mas Zig também nunca teve como objetivo um ecossistema gigantesco
• Não existe registro oficial de pacotes, e a posição é de que não há necessidade de outro NPM ou crates.io
• Hoje Zig é avaliado como tendo alcançado um equilíbrio adequado

A forma de encarar segurança de memória

• Zig não oferece garantias de segurança de memória como Rust
• Isso é um trade-off em favor da simplicidade, e a complexidade dos tipos afins de Rust não parece valer tanto quanto o ganho de segurança
• Isso não significa que Zig tenha abandonado a segurança
• Pela perspectiva de Zig is safer than unsafe Rust, Zig pode ser uma escolha melhor nas situações em que seria necessário usar unsafe Rust
• Zig também está trabalhando para tornar a linguagem mais segura
  • a abordagem foca no modo de release, não em regiões de código unsafe
  • atualmente, o modo ReleaseSafe do Zig trava em caso de falha de assertion e inicializa toda a memória
  • Andrew Kelley tem interesse em incluir algo como Fil-C no ReleaseSafe
• Essa abordagem não oferece a segurança de memória em tempo de compilação do Rust sem unsafe, mas também não me parece a espiral de morte de que alguns falam
• Segurança de memória é um espectro, e não existe uma única abordagem melhor para todas as situações
• A abordagem do Zig é tornar o ReleaseSafe o mais seguro possível em tempo de execução e verificar a correção com testes e fuzzing
• Comportamentos ilegais não verificados devem ser encontrados nesse processo, e, depois que a correção for comprovada, considera-se seguro distribuir binários de outros modos de release
• Essa abordagem tem desvantagens em comparação com o modelo do Rust, mas, dentro da forte busca por simplicidade do Zig, não a considero estritamente inferior
• Se segurança de memória em tempo de compilação for importante o bastante para justificar o custo de um sistema de tipos complexo e tempos longos de compilação, então basta escolher Rust
• O modelo de segurança de memória do Zig também se conecta à sua filosofia de assertions
  • em vez de desativar assertions no ReleaseFast, confia-se que os testes provaram que as assertions estão corretas e que aquele caminho é unreachable
  • isso permite ao Zig otimizar o código
  • um texto relacionado é your assertions are correct

Como pretendo usar daqui para frente

• Estou pronto para lidar com problemas de software em Zig, mantendo por perto a biblioteca padrão e o histórico de mudanças de release
• Quando eu não quiser lidar com detalhes de baixo nível, pretendo usar minha linguagem de script preferida
• Meu plano é usar Zig como ferramenta principal nos próximos softwares
• Continuo aberto à possibilidade de não permanecer em Zig para sempre
  • posso usar Rust se precisar da estabilidade ou do sistema de tipos dele
  • posso mudar completamente de opinião sobre a abordagem do Zig
  • várias linguagens podem e devem coexistir
• Zig representa uma visão de software focada no usuário, ao aceitar a qualidade de software sem ignorá-la
• As pessoas merecem software confiável e poderoso, e, na era dos LLMs, software feito com cuidado está ficando raro, enquanto as pessoas são pressionadas a aceitar um slop cada vez pior

[clastneo]

Tive uma experiência em que desisti de aprender Zig no meio do caminho ao ver comentários de que uma nova versão estava para sair.
Quando sair uma versão estável, talvez valha a pena colocá-lo de volta na minha lista de estudos, mas, por enquanto, as breaking changes ainda são tão intensas que dá medo de mexer.

[click]

Como o Zig continua mudando a especificação da linguagem e descartando a compatibilidade retroativa, acho que fica difícil usá-lo em sistemas importantes, pelo menos até a versão 1.0 sair.
Parece que o ghostty está sofrendo bastante por causa da mudança em std.IO: issue
Para dar um exemplo de outra linguagem: se, depois que Future surgiu em Java, a API JDBC tivesse passado a retornar Future ou CompletableFuture, certamente teria sido um grande avanço, mas o preço teria sido uma enorme confusão.

[GN⁺]

Comentários no Lobste.rs

• Quero tentar usar Zig de novo algum dia
  Tenho muita vontade mesmo, mas até agora estive ocupado com outras coisas
  Da última vez que mexi com Zig, encontrei um erro no compilador em cerca de 3 horas, e isso deixou uma impressão forte. Para ser justo, aquele bug já estava corrigido no branch mais recente

• Fico em dúvida quanto à afirmação de que, “por estar preso ao LLVM, levará muito tempo para dar suporte a tantas plataformas quanto C, ou talvez nunca consiga”
  Tenho curiosidade sobre quais plataformas que o LLVM não suporta alguém gostaria de ter como alvo, e como Zig seria melhor nesse ponto
  Gostaria de perguntar se a ideia é que Zig gere código C tier-4, e que o GCC possa compilá-lo para hppa, alpha e sh

  • Pelo que entendi, Zig está trabalhando ativamente para reduzir a dependência do LLVM, então a ideia parecia ser mais que, no futuro, ao implementar novos alvos no compilador Zig, talvez não seja necessário mexer no próprio projeto LLVM
  • Atualmente, a forma de implementação disso é a geração de código C
    O problema é que Zig tem um backend oficial além do LLVM, enquanto Rust usa LLVM
    Se uma linguagem de sistemas busca maximizar a reutilização de software, ela deve rodar no maior número possível de ambientes, e isso vale especialmente se a intenção é substituir C, como no caso de Zig
  • Pelo que lembro vagamente, a preocupação parecia estar mais ligada ao tempo de compilação do que ao suporte a plataformas

• Vendo o sucesso do ghostty, pretendo usar Zig em desenvolvimento de jogos quando ele chegar à versão 1.0
  Mas não tenho certeza se os tipos de jogos que faço realmente precisam desse nível de desempenho

  • Se você conhece Godot, pode experimentar https://github.com/godot-zig/godot-zig

• É bem comum ouvir algo como “Zig não abriu mão da segurança e é mais seguro que unsafe Rust. Se você de qualquer forma precisa usar unsafe Rust, Zig pode ser melhor”, mas sempre que vejo isso, não consigo entender muito bem
  Acho estranho especialmente porque o autor reconhece que segurança é um espectro, mas ainda assim recomenda trocar por uma linguagem em que tudo continua sendo unsafe, em vez de usar regiões unsafe localizadas
  Talvez a máquina abstrata seja um pouco mais fácil de raciocinar, mas essa troca não me convence