Zig – adicionado suporte a io_uring e Grand Central Dispatch ao std.Io

• O módulo std.Io.Evented da biblioteca padrão do Zig passou a integrar novas implementações baseadas em io_uring e Grand Central Dispatch (GCD)
• As duas implementações operam com troca de pilha em espaço de usuário (fibers, stackful coroutines, green threads)
• No momento, estão em fase experimental, e ainda exigem trabalhos posteriores como melhoria no tratamento de erros, remoção de logs, análise das causas de degradação de desempenho e reforço dos testes
• No mesmo código de aplicação, é possível trocar apenas o backend de I/O para alternar facilmente entre io_uring ou GCD
• As duas implementações também funcionam no compilador Zig, e no futuro podem evoluir para uma base unificada de I/O assíncrono por plataforma quando forem estabilizadas

---

Implementação de std.Io.Evented baseada em io_uring e GCD

• No fim do ciclo de lançamento do Zig 0.16.0, o std.Io.Evented foi atualizado para refletir as mudanças mais recentes da API

  • As implementações recém-adicionadas são io_uring (Linux) e Grand Central Dispatch (GCD) (macOS)
  • Ambas usam a tecnologia de troca de pilha em espaço de usuário (fibers, stackful coroutines, green threads)

• As duas implementações estão atualmente em estado experimental, e ainda há várias tarefas de melhoria para uso estável

  • É necessário melhorar o tratamento de erros
  • É preciso remover os logs e diagnosticar a causa da degradação de desempenho (há perda de desempenho no compilador ao usar IoMode.evented)
  • Existem algumas funções ainda não implementadas e é necessário ampliar a cobertura de testes
  • É preciso adicionar uma função embutida para verificar o tamanho máximo de pilha por função (com o objetivo de viabilizar o uso prático quando overcommit estiver desativado)

Exemplo de troca de implementação de I/O

• É possível executar o mesmo código de aplicação trocando apenas o backend de I/O

  • No código de exemplo, usar std.Io.Evented em vez de std.Io.Threaded faz a execução acontecer com base em io_uring
  • A função app permanece a mesma, e o resultado de saída (Hello, World!) também é idêntico

• A diferença entre os dois modos de execução pode ser vista pela comparação dos resultados do strace

  • hello_threaded usa chamadas de I/O baseadas em threads convencionais
  • hello_evented usa chamadas de sistema do io_uring (io_uring_setup, io_uring_enter etc.)

Aplicação no compilador Zig e situação atual

• O próprio compilador Zig também funciona normalmente usando std.Io.Evented

  • É possível executar o compilador tanto com io_uring quanto com GCD
  • Porém, a causa da degradação de desempenho ainda não foi identificada, então análises adicionais são necessárias

• Essa mudança aproxima o Zig de uma estrutura em que o código pode trocar facilmente a implementação de I/O

  • Isso cria a base para lidar de forma unificada com modelos de I/O assíncrono específicos de cada plataforma

Próximas tarefas

• São necessárias melhorias de desempenho e reforço dos testes para uso estável
• Com a adição de funcionalidades de gerenciamento de tamanho de pilha, o uso prático poderá ser viável mesmo em ambientes com overcommit desativado
• Quando estiver concluída, a camada de abstração de I/O assíncrono do Zig deverá ficar ainda mais robusta

Conclusão

• Esta atualização representa um avanço importante na expansão do sistema de I/O padrão do Zig
• Ao integrar io_uring e GCD, foi criada a base para garantir consistência no processamento assíncrono entre plataformas
• Quando o trabalho de estabilização for concluído, amplia-se a possibilidade de o Zig oferecer um modelo de I/O de alto desempenho e flexível

[GN⁺]

Comentários do Hacker News

• Não sou fã de Zig, mas é bom ver uma equipe pequena evoluindo de forma consistente
  A postura de priorizar experimentação e melhorias graduais, em vez de completude, é impressionante
  Acho mais importante avançar em direção a objetivos de longo prazo do que apressar um 1.0
  Para um projeto tão centrado em uma pessoa, é uma conquista surpreendente, e as pessoas envolvidas merecem o devido reconhecimento

  • Toda vez que aprendo uma linguagem nova, tento criar um motor de jogo com servidor multiplayer TCP/UDP, e recentemente fiz isso em Zig
    Foi a experiência mais divertida e produtiva que já tive até agora
    A simplicidade de Zig combina muito mais comigo do que a gestão rígida de memória do Rust
    A vida é curta, e eu só quero criar software rápido e bem organizado

• Todo texto sobre Zig recebe muitas críticas, mas não entendo por que tanta gente se importa tanto
  O espírito de engenharia do Andrew e da equipe, tentando concretizar aquilo em que acreditam, é justamente o que inspira
  Não precisa se preocupar se Zig vai virar mainstream; se ajuda a resolver problemas, isso já basta
  Não faz sentido tratar linguagem como identidade

  • Para acabar com esse fenômeno, seria preciso mudar os incentivos econômicos que os programadores recebem
    Linguagens e bibliotecas acabam sendo “habilidades vendáveis”, então as pessoas pensam no valor de mercado das ferramentas que usam
    Além disso, também é um problema o fato de tomadores de decisão tratarem engenheiros como ativos substituíveis
  • Essas discussões sobre linguagens não são exclusivas de Zig
    Já se repetiram com Lisp, Ruby, Rust e outras, e essa briga de identidade é um problema crônico da indústria
  • Uma nova stack de linguagem aumenta a carga de manutenção em distribuições Linux
    Mesmo exigindo gestão de longo prazo em segurança, suporte de arquitetura e afins, os desenvolvedores costumam ignorar esse custo
    Zig ainda não é estável, então há pacotes que só compilam em versões específicas
    Fico em dúvida se realmente faz sentido resolver com uma nova linguagem problemas que poderiam ser resolvidos com melhorias em outras
  • Para se tornar uma linguagem dominante, é preciso um ecossistema de bibliotecas previsível que cubra a maioria dos casos de uso

• Sinto que não faz muito sentido acompanhar Zig antes de chegar ao 1.0
  A estrutura atual provavelmente ainda será refeita várias vezes
  Eu também já me interessei, mas nem sei se vou ver um 1.0 em vida

  • Na prática, as quebras de compatibilidade em Zig acontecem principalmente na biblioteca padrão (stdlib)
    Funções básicas como entrada e saída de arquivos quase não mudam; o que muda mais são os namespaces
    Eu acho melhor ter uma “linguagem viva”
    Mesmo depois da série 1.x, seria bom ter uma estratégia de gestão de interfaces por versão para manter a stdlib enxuta
  • Gosto da linguagem Zig em si, mas comecei a questionar a qualidade da stdlib
    Ao criar meu próprio framework de I/O, encontrei falta de testes e código assembly incorreto
    Apontei isso várias vezes, mas não foi corrigido, então minha confiança caiu
  • Para projetos grandes talvez haja hesitação, mas Zig já tem valor comercial
    Especialmente em ambientes de nuvem, otimizações de performance podem reduzir custos de servidor em mais de 90%
    Com Python ou Node isso tem limite, então no fim você precisa descer para C, C++, Rust ou Zig
    Entre eles, Zig é fácil de aprender e confortável de ler e testar
  • Vale lembrar que o Bun também foi escrito em Zig
    Já é uma linguagem usada em nível profissional
  • Nossa equipe (ZML) vem acompanhando continuamente a branch master do Zig desde a adoção de std.Io
    A maior parte das mudanças realmente parece ser melhoria da linguagem

• É interessante que Zig esteja tentando implementar isso antes, enquanto o suporte a io_uring no Rust ainda não está pronto
  No Rust, é difícil projetar abstrações seguras e de custo zero

• Esta notícia ainda é sobre uma implementação incompleta
  Por exemplo, a versão com GCD não tem networking
  A interface está crescendo cada vez mais, então parece mais um snapshot atual do que algo acabado

  • Mas o próprio começo do texto já deixa claro que está em fase experimental,
    e lista de forma concreta seis tarefas principais que ainda precisam ser feitas

• Existe uma issue sobre otimização de memória de stack
  É necessário um recurso que faça com que, mesmo usando [500]u8 em blocos diferentes, o stack frame ocupe apenas 500 bytes
  Isso é especialmente importante em relação à stack de corrotinas com green threads

• Vejo de forma positiva o esforço contínuo de melhoria no Zig
  Hoje não existe linguagem que lide direito com io_uring
  Se Zig resolver bem esse ponto, vai conquistar uma grande vantagem
  Acho mais valioso priorizar aprendizado e experimentação do que estabilidade

  • É interessante querer async até em uma linguagem de baixo nível
    Eu prefiro, no Zig, usar libxev e controlar io_uring diretamente
  • Eu também sou positivo, mas fico curioso sobre quando Zig vai lançar uma versão estável de longo prazo (LTS) como o C
    O sucesso do C veio da estabilidade e de uma cultura de desenvolvimento consistente

• Gosto que Zig trate os targets freestanding com seriedade
  Espero que a reutilização de código melhore ainda mais na versão 0.16

• Fazia tempo que eu não olhava por dentro do macOS, e fiquei feliz em ver que mantiveram o GCD
  Acho que é uma abordagem equilibrada para paralelismo

• Enquanto outras linguagens ficam só debatendo, Zig tenta de fato, e volta atrás se necessário
  Acredito que APIs validadas na prática são o melhor tipo de design
  Você pode continuar usando versões antigas, ou ir para a mais nova e ganhar ferramentas mais limpas e rápidas

  • Jai é focada em desenvolvimento de jogos, então fica devendo em termos de propósito geral e segurança
    É complexa como C++, enquanto Zig mantém a simplicidade de C
    Carbon ainda está num estado sem substância concreta
  • É estranho criticar Zig por ainda não ser 1.0
    Jai está há 11 anos em beta fechado, enquanto Zig já é usado em vários projetos reais
  • Acho melhor uma linguagem levar 20 anos e ficar realmente pronta
    As mudanças desenfreadas que vimos em Python 2→3, async no Rust, genéricos no Go, C++ e outros acabaram sendo mais prejudiciais