Zig 0.17.0 traz um sistema de build dividido e rebuilds rápidos

O projeto Zig lançou o Zig 0.17.0 em 2 de outubro de 2026, depois de cinco meses de trabalho. A principal mudança é um sistema de build reconstruído que separa a configuração da execução, além de compilação incremental que funciona para a maioria dos projetos no Linux x86_64. Zig é uma linguagem de programação de sistemas usada com frequência como alternativa moderna ao C. Para quem usa Zig, a versão significa rebuilds mais rápidos, mas também uma longa lista de mudanças incompatíveis e, por enquanto, a integração com editores quebrada.

O que há no Zig 0.17.0

As notas de lançamento dizem que o 0.17.0 reúne mudanças de 206 colaboradores em 925 commits. O LWN.net, que cobriu o lançamento em 3 de outubro, observa que o ciclo foi maior e mais longo do que o esperado no início. As principais partes:

Área	Mudança no 0.17.0
Sistema de build	Configuração e execução agora rodam como processos separados
Ferramentas	Um novo Build Server Protocol para ferramentas de terceiros
Compilação	Builds incrementais para a maioria dos projetos Linux x86_64
Linker	O linker ELF ganha suporte completo a x86_64, SPARC64, bibliotecas e informações de depuração
LLVM	Atualizado para o LLVM 22.1.8
Alvos	Adiciona loongarch32, aarch64-switch, arm-gba e xtensa-linux

Sobre o LLVM, as notas mencionam uma solução provisória para a vetorização de loops que fica em vigor até o LLVM 23. O LLVM é o conjunto de ferramentas de compilação que o Zig usa para gerar código de máquina otimizado.

Como funciona o novo sistema de build

Um projeto Zig descreve o seu build em um arquivo chamado build.zig, escrito no próprio Zig. Até agora, um único processo compilava esse arquivo e também executava o build inteiro.

No 0.17.0, esse trabalho é dividido em dois. O Squared Tech descreveu o design em maio, quando ele ainda estava em desenvolvimento. Um processo "configurer" compila o build.zig em modo debug para definir as etapas do build. Um processo "maker" separado, compilado em modo release, executa então o build.

A divisão compensa em velocidade. Uma publicação no blog bokvi relata que zig build -h caiu de 150 milissegundos para 14,3 milissegundos em maio de 2026, quando a reformulação chegou ao branch de desenvolvimento.

Compilação incremental, agora prática

Compilação incremental significa recompilar só o código que mudou, em vez do programa inteiro. As notas de lançamento dizem que agora ela funciona para a maioria dos projetos voltados ao Linux x86_64. Os desenvolvedores a ativam com zig build -fincremental --watch. O sistema de build então observa os arquivos-fonte e recompila quase instantaneamente após cada edição.

Isso se apoia em meses de trabalho. Em maio, o Squared Tech relatou rebuilds incrementais de 228 a 288 milissegundos em um projeto cujo build completo levava cerca de 36 segundos. Naquele momento, o modo incremental também funcionava com bibliotecas externas e arquivos-fonte em C. Ainda faltavam as informações de depuração DWARF, os dados que os depuradores usam para mapear o código de máquina de volta às linhas do código-fonte. As notas do 0.17.0 listam o suporte a DWARF como parte do linker ELF aprimorado.

O modo incremental vem desativado por padrão e só roda no Linux x86_64, segundo o Squared Tech.

As mudanças incompatíveis

O Zig ainda não chegou à versão 1.0, e esta versão quebra muito código. As notas de lançamento listam estas entre as mudanças:

• @bitCast foi redesenhado.
• @intFromEnum e @enumFromInt são substituídos por @backingInt e @fromBackingInt.
• A sintaxe de multiplicação de arrays foi removida.
• A sintaxe void{} foi removida.
• errdefer não pode mais capturar valores.
• @cImport, o built-in para importar headers C diretamente, está obsoleto.

Dois alvos foram removidos: powerpc-linux-gnueabi e powerpc64-linux-gnu.

O suporte a editores está quebrado por enquanto

A nova divisão de processos tem um custo. As notas de lançamento dizem que a separação dos processos maker e configurer quebra a integração com o ZLS, o Zig Language Server. O ZLS é o que dá aos editores autocompletar e ir para a definição em Zig. As notas dizem que o trabalho no Build Server Protocol está em andamento para restaurá-la.

O que isso significa para desenvolvedores

Não atualize um projeto que funciona no meio de um prazo. A lista de sintaxe removida e de built-ins renomeados significa que a maioria das bases de código não triviais vai precisar de edições. Tenha cuidado redobrado com @bitCast, já que uma conversão redesenhada pode mudar o comportamento de formas que uma leitura rápida não pega. Leia essa seção das notas de lançamento antes de confiar em casts antigos.

Pense no seu editor. Se você depende do ZLS para autocompletar, fique no 0.16 até o ZLS suportar o 0.17.0, ou aceite editar em texto puro por enquanto.

Experimente os builds incrementais se você trabalha no Linux x86_64. Rode zig build -fincremental --watch em um branch e meça o seu próprio tempo entre editar e rodar. Os rebuilds abaixo de 300 milissegundos do Squared Tech vieram de um único projeto, então os seus números vão ser diferentes.

Se você usa o Zig principalmente como compilador C ou para chamar código C, verifique cada @cImport. Ele está obsoleto no 0.17.0, então planeje a migração antes que uma versão futura o remova.