Backend x86 self-hosted passa a ser o padrão no modo debug

• Agora, para o alvo x86_64, o backend x86 próprio do Zig passa a ser aplicado por padrão no modo debug
• Em comparação com a base anterior em LLVM, ele alcançou mais testes de comportamento aprovados e compilação mais rápida
• Com a adoção do backend próprio, o Zig obteve grande redução no tempo de compilação e aumento de eficiência em algumas tarefas
• Também avançaram vários reforços de recursos, como o sistema de build recentemente aprimorado, a expansão do suporte a sistemas BSD e melhorias no runtime do UBSan
• A biblioteca padrão e as ferramentas próprias otimizadas destacam a competitividade exclusiva do Zig

---

Resumo das principais novidades mais recentes

8 de junho de 2025 – backend x86 self-hosted passa a ser o padrão no modo debug

• No alvo x86_64, agora o backend x86 próprio do Zig é usado por padrão
  • Antes, era usado o LLVM para converter bitcode em arquivo objeto
  • No Windows, a mudança foi adiada porque ainda há trabalho adicional necessário no linker COFF
• O backend x86 do Zig passou em 1.987 testes de comportamento, mostrando estabilidade superior à do backend LLVM (1.980)
  • O total de testes é 2.084, mas alguns se sobrepõem aos próprios testes do LLVM, então a verificação adicional é feita apenas ao testar o backend próprio
• O principal motivo para o Zig focar no desenvolvimento de um gerador de código próprio é superar amplamente o LLVM em velocidade de build
  • Nos resultados de benchmark, o tempo médio de build de zig build-exe hello.zig -fllvm (usando LLVM) foi de 918 ms, enquanto o backend próprio registrou 275 ms
  • É possível confirmar grandes melhorias em todos os aspectos, incluindo uso de memória, ciclos de CPU, número de instruções e cache misses
  • O tempo de build de projetos grandes, como o próprio compilador Zig, também caiu de 75 segundos para 20 segundos
• Para o futuro, estão previstos a paralelização completa da geração de código, reforços nas capacidades de linking e o desenvolvimento do backend aarch64
  • A introdução de um novo passe Legalize também deve acelerar o trabalho em aarch64
• As mudanças mais recentes podem ser experimentadas diretamente nas builds mais atuais da branch master do Zig

6 de junho de 2025 – vídeo de apresentação do sistema de build

• Foi publicado um vídeo-guia no YouTube para iniciantes no sistema de build do Zig
  • Ele explica como criar módulos e pacotes Zig e como importá-los em outros projetos
  • Mais vídeos sobre o sistema de build também devem ser adicionados continuamente como parte da série

20 de maio de 2025 – suporte reforçado a alvos FreeBSD e NetBSD

• Com a fusão dos Pull Requests #23835 e #23913, passou a ser possível compilar binários para os alvos FreeBSD 14.0.0+ e NetBSD 10.1+ com zig cc e zig build
  • A estratégia de extrair informações da libc e de bibliotecas relacionadas, antes aplicada no glibc, foi estendida também à família BSD
  • Os arquivos abilists gerados são distribuídos junto com o Zig, permitindo criar bibliotecas stub que correspondem com precisão a cada biblioteca libc durante a compilação cruzada
  • Os headers do sistema e da libc também são fornecidos com base na versão mais recente do sistema operacional
  • OpenBSD, Dragonfly BSD, SerenityOS, Android e Fuchsia também estão na mira de suporte

9 de abril de 2025 – site oficial do Zig passa a ser construído como um Zine standalone

• A estrutura do site oficial do Zig agora foi alterada para ser construída como um Zine standalone
  • Ele evoluiu de um script de build existente para um único executável
  • O texto indica que este é um bom momento para experimentá-lo diretamente

Notícias de release e melhorias de recursos

• O release 0.14.0 deve ser distribuído em breve, e melhorias notáveis já foram aplicadas
• Com melhorias na interoperabilidade com C e no runtime do UBSan (Undefined Behavior Sanitizer), erros SIGILL antes ambíguos passaram a ser substituídos por mensagens de erro específicas e úteis
  • Exemplo: o local e a causa de um overflow de inteiro com sinal são mostrados claramente, aumentando muito a eficiência de depuração
• Limitações restantes do UBSan:
  • Sem suporte para verificação de tipo dinâmico e ciclo de vida relacionados a vptr em C++
  • A indicação precisa de localização para atributos como assume_aligned e __nonnull ainda não foi concluída

7 de fevereiro de 2025 – inovações no debug allocator e no SmpAllocator

• O debug allocator foi redesenhado para oferecer suporte ao reconhecimento do tamanho de página em runtime e refletir diversas otimizações
  • Redução na criação de memory maps, remoção de repetições desnecessárias de memset 0xaa/0x00 e eliminação de estruturas de dados de busca e trip
  • Os metadados são armazenados inline dentro da página, facilitando a implementação de erros de compilação e validação
  • Em comparação com o malloc tradicional baseado em C, houve ganho de legibilidade e manutenibilidade
• Com o desenvolvimento do SmpAllocator, otimizado para ambientes concorrentes, a eficiência de execução da alocação de memória em ambientes multi-thread foi maximizada
  • Benchmarks comparando com o glibc comprovaram na prática a velocidade e a eficiência no uso de recursos
  • Como resultado, isso é avaliado como um importante ponto de virada em que a usabilidade do Zig supera C e libc

24 de janeiro de 2025 – ambiente de depuração dedicado ao Zig

• Jacob desenvolveu um fork do LLDB (depurador) para Zig, reforçando o suporte de depuração do backend próprio
  • A forma de compilar e usar o fork do LLDB é fornecida em documentação na wiki
  • Desenvolvedores que usam o backend próprio do Zig podem aproveitar um ambiente de depuração mais refinado com essa ferramenta

Conclusão

• O Zig segue promovendo mudanças inovadoras com foco principal em ganho de desempenho, eficiência de build e maior conveniência para depuração
• Está garantindo competitividade diferenciada em algoritmos independentes, compilador e também nas ferramentas de build/runtime
• Incluindo suporte a várias plataformas como BSD, melhorias em mensagens voltadas ao usuário e inovação no modelo de memória, o projeto continua entregando avanços realmente úteis para profissionais de engenharia de software

[GN⁺]

Comentários do Hacker News

• Pelo que sei, o Zig está trabalhando diariamente em vários recursos para melhorar a experiência de desenvolvimento. Por exemplo, recentemente houve este PR. No passado, hot code swapping também estava nos planos de desenvolvimento do Zig e, nesse ritmo, imagino que esse recurso possa estar disponível em x86_64 dentro de um ano. Pessoalmente, o maior incômodo que sinto é a velocidade do comptime. Houve um experimento rodando uma DSL de brainF** em tempo de compilação, e foi realmente muito lento (mas foi um experimento divertido). Fico curioso para saber quando essa parte do compilador vai melhorar. Também estou muito empolgado com os novos backends, e quero até tentar criar meu próprio backend URCL para Zig 😉

  • Sobre melhorar o desempenho do comptime, já sabemos o que precisa ser feito e até começamos um branch relacionado há bastante tempo. Mas isso exige retrabalhar o código de análise semântica em uma escala significativa, então, embora seja uma das tarefas importantes, ainda disputa prioridade com outras coisas

  • Hot code swapping é um recurso que pode causar uma transformação enorme no desenvolvimento de jogos. Acho impressionante que no Zig isso esteja planejado para ser suportado basicamente por uma flag do compilador. Com clang, é algo que mal dá para tentar

  • Não olhei URCL a fundo, mas isso está me levando para outra toca de coelho. Fico imaginando um cenário realmente bizarro em que um IR criado para Minecraft acabe virando um alvo real de compilação de uma linguagem

  • Fico curioso se criar backends customizados é fácil. Ainda não tentei pessoalmente, mas tenho vontade de fazer um experimento de backend que receba AIR e produza relatórios de segurança de memória (por exemplo, checando uso de valores indefinidos, escape de ponteiro de stack, use-after-free, double free, alias xor mut etc.)

  • Tenho curiosidade se comptime lento é realmente um problema. Estou fazendo uma biblioteca JSON-RPC e, em tempo de compilação, uso bastante comptime para despachar JSON para funções arbitrárias. Como com a tipagem estática forte do Zig não é possível fazer despacho dinâmico em runtime para funções com parâmetros arbitrários, acabei tendo que gerar, em tempo de compilação, um mapeamento dos tipos das funções. O que me preocupa é que isso inevitavelmente aumenta o tamanho do binário, porque o código comptimado é copiado para cada função

• Só de já ter chegado até esse ponto, já é um feito impressionante. Como foi dito no devlog, o que vem pela frente parece ainda mais promissor. A ideia de o compilador alterar apenas as partes necessárias do binário na hora de buildar parece algo novo e radical, e graças ao projeto Zig isso agora virou uma meta viável. Tempos muito interessantes pela frente

• Há menção de que, em projetos grandes como o próprio compilador Zig, o tempo de build caiu de 75 segundos para 20 segundos.
  Fico muito curioso para saber até onde isso ainda pode melhorar. Tenho a impressão de que os desenvolvedores do Zig são muito inteligentes.
  Também fico curioso sobre como é o gerenciamento de pacotes. No passado tentei fazer um app com QuickJS + SDL3 em Zig, mas acabei indo para Rust por causa da complexidade do C++. Quero tentar de novo em Zig

  • O gerenciamento de pacotes do Zig é mais manual do que no Rust. Você busca diretamente a URL do pacote na CLI e importa o módulo no script de build. A vantagem disso é que até arquivos compactados arbitrários podem ser usados facilmente como dependências, e muitos pacotes de bibliotecas C para Zig simplesmente conectam releases untouched (tarball) diretamente no script de build. Mas para iniciantes isso pode ser um pouco complicado
    No caso do SDL3, há dois caminhos: o wrapper nativo em Zig (https://github.com/Gota7/zig-sdl3) e o https://github.com/castholm/SDL, que é uma versão mais simples que "zigifica" a biblioteca/API em C
    O QuickJS suporta apenas a API C (https://github.com/allyourcodebase/quickjs-ng)
    O Zig facilita muito o uso direto de pacotes em C, mas como a tipagem é rígida, pode ser necessário fazer casts de tipo com frequência ao lidar com a API

  • O compilador D dmd consegue compilar a si mesmo em cerca de 18,4 segundos em build de debug.
    Meu processador é um AMD Athlon 64 X2 (4400+) bem antigo, mas roda tão rápido que eu ainda nem fiz upgrade
    (inclui uma lista detalhada das informações da CPU)

  • Fico curioso se existe um guia para compilar o Zig em 20 segundos para ter um ciclo de desenvolvimento rápido. Da última vez que compilei Zig, havia vários estágios envolvidos (principalmente o bootstrap em WASM), então levava bastante tempo

  • É impressionante que o Zig consiga compilar a si mesmo em 75 segundos mesmo ainda usando LLVM

• Não tenho nenhuma intenção de exigir demais do Zig, e sei muito bem que é open source, mas o que mais me interessa é um cronograma realista para o lançamento 1.0.
  O Zig é quase exatamente a linguagem que eu sempre quis em uma linguagem de baixo nível, e agora só estou esperando a estabilização.
  E realmente admiro a filosofia de design minimalista do Zig

  • Pelo que sei, projetos reais como o tigerbeetle normalmente fixam uma versão de release para uso e deixam nightly apenas para experimentos

• Como completo iniciante, fico curioso sobre quais são as vantagens do Zig em comparação com outras linguagens. Eu o entendo como um C mais moderno, mas queria saber o que exatamente há de “moderno” nele

  • Algumas vantagens que me vêm à cabeça agora
    • sistema de build integrado, sem precisar combinar várias ferramentas e linguagens separadas
    • slices com tamanho explícito no lugar dos arrays do C (e seus problemas de buffer overflow)
    • tipo optional claro, com ponteiros nulos não permitidos por padrão (e, quando necessário, o tipo deixa isso explícito)
    • enum, tagged union e checagem obrigatória de exaustividade em switch
    • tratamento de erros explícito (meio no estilo Rust). Se uma função pode retornar erro, o chamador não pode simplesmente ignorar. Não é como em C, onde o valor de retorno pode passar batido. Por outro lado, é uma pena não haver sintaxe padrão para retornar erro e dado ao mesmo tempo
    • blocos defer e errdefer para implementar limpeza automática no retorno da função ou em caso de erro
    • geração de código com comptime no lugar de macros, reflexão de tipos (@typeInfo etc.)
    • o alocador de memória é gerenciado diretamente pelo chamador (mais poder de decisão sobre onde e como a memória é usada)
    • usando GeneralPurposeAllocator (para iniciantes), fica mais fácil rastrear vazamentos de memória
      Eu nunca me dei muito bem com C, e sempre senti uma barreira de entrada para programação de baixo nível por causa de várias coisas pouco razoáveis e pouco intuitivas da linguagem. O Zig foi a primeira linguagem que me fez sentir diversão e interesse de verdade por programação de sistemas

• Fico curioso se existe um guia para compilar o Zig em 20 segundos. Queria acelerar o ciclo de desenvolvimento, mas já tive a experiência de achar difícil contribuir porque stage1/2/3 demoravam bastante para compilar

• Se ao compilar um hello world com zig init no Zig o resultado dá 9,3 MB, usar a flag -Doptimize=ReleaseSmall reduz isso para 7,6 KB
  É uma diferença de mais de 1000 vezes com uma única flag

  • Na prática, 82% dessa diferença vem das informações de debug
    -OReleaseSmall -fno-strip dá 580 KB, e -ODebug -fstrip pode chegar a 1,4 MB
    Com o backend x86 do Zig, existe um fork do LLDB específico para Zig que oferece uma experiência de depuração muito melhor
    Não lembro se hoje já é possível depurar a lógica de comptime passo a passo, mas isso foi tema de discussão recente

• Acho que a Julia poderia considerar Zig como compilador para obter vantagens de desempenho. Também me lembro da ansiedade dos desenvolvedores de Julia a cada release por medo de regressões de performance

  • A Julia, na prática, é fortemente acoplada ao LLVM. Várias partes do ecossistema dependem da existência de LLVM intrinsics, autodiff (Enzyme), compilação para GPU etc.
    O compilador está se tornando bem retargetable, e essa área também está sendo pesquisada ativamente agora.
    No futuro, dá para imaginar o Zig como compilador alternativo para partes da linguagem

  • Há quem diga que o próprio LLVM é a API pública da Julia. Na prática, existem até macros como @code_llvm que mostram diretamente o IR

  • Certamente ajudaria a reduzir o tempo de compilação, mas a Julia ainda tem muito trabalho pela frente
    Há espaço para granular melhor o cache de compilação, criar tooling para evitar invalidation, remover a otimização de world splitting, usar mais multithreading no compilador, fazer pré-compilação automática para certas assinaturas e até compilar/trocar código em hot swap de forma lazy

• Isso é um avanço enorme para o Zig, e acho que será uma das principais formas de diferenciação em relação ao Rust daqui para frente. Aliás, fui eu quem escreveu a maior parte do código de renderização da ferramenta de análise de performance, então fico feliz em ver meu código sendo usado amplamente online
  link do projeto poop

  • O Rust também tem uma tentativa parecida usando cranelift
    Veja rustc_codegen_cranelift

• Acho que isso é justamente uma das pré-condições para trazer de volta o recurso de async/await no Zig
  Vale ver também o FAQ oficial do Zig sobre async

  • Essa parte já está toda mapeada, e devemos conseguir divulgar uma atualização interessante nos próximos 2 ou 3 meses. Estamos praticamente refazendo toda a camada de I/O, como se estivéssemos criando a biblioteca padrão de novo

  • Pelo que diz o link, parece que o async pode nem voltar, ou pelo menos continua sendo algo fora de cogitação até 2028