Zig – Se agrega una implementación de std.Io con io_uring y Grand Central Dispatch

• Se integró una nueva implementación basada en io_uring y Grand Central Dispatch (GCD) en el módulo std.Io.Evented de la biblioteca estándar de Zig
• Ambas implementaciones funcionan mediante cambio de pila en espacio de usuario (fibers, corrutinas con pila, green threads)
• Por ahora están en una fase experimental y todavía requieren trabajo posterior, como mejorar el manejo de errores, eliminar el registro, analizar la causa de la degradación de rendimiento y reforzar las pruebas
• En el mismo código de aplicación, es posible cambiar fácilmente entre io_uring o GCD solo reemplazando el backend de I/O
• Las dos implementaciones también funcionan en el compilador de Zig, y si se estabilizan en el futuro, podrían evolucionar como una base unificada de I/O asíncrono por plataforma

---

Implementación de std.Io.Evented basada en io_uring y GCD

• Hacia el final del ciclo de lanzamiento de Zig 0.16.0, std.Io.Evented se actualizó para reflejar los cambios más recientes de la API

  • Las implementaciones agregadas recientemente son io_uring (Linux) y Grand Central Dispatch (GCD) (macOS)
  • Ambas implementaciones usan la técnica de cambio de pila en espacio de usuario (fibers, corrutinas con pila, green threads)

• Por ahora, ambas implementaciones están en estado experimental, y aún quedan varias tareas de mejora para un uso estable

  • Hace falta mejorar el manejo de errores
  • Hace falta eliminar el registro y diagnosticar la causa de la degradación de rendimiento (se presenta una caída de rendimiento del compilador al usar IoMode.evented)
  • Existen algunas funciones aún no implementadas y es necesario ampliar la cobertura de pruebas
  • Hace falta agregar una función integrada para verificar el tamaño máximo de pila por función (con el fin de asegurar utilidad práctica cuando overcommit está desactivado)

Ejemplo de reemplazo de implementación de I/O

• Es posible ejecutar el mismo código de aplicación cambiando solo el backend de I/O

  • En el código de ejemplo, si se usa std.Io.Evented en lugar de std.Io.Threaded, se ejecuta sobre io_uring
  • La función app es la misma y el resultado de salida (Hello, World!) también es el mismo

• La diferencia entre ambos modos de ejecución puede verse comparando los resultados de strace

  • hello_threaded usa llamadas de I/O basadas en hilos convencionales
  • hello_evented usa llamadas al sistema de io_uring (io_uring_setup, io_uring_enter, etc.)

Aplicación en el compilador de Zig y estado actual

• El propio compilador de Zig también funciona correctamente usando std.Io.Evented

  • El compilador puede ejecutarse tanto con io_uring como con GCD
  • Sin embargo, como todavía no se conoce la causa de la degradación de rendimiento, hace falta un análisis adicional

• Con este cambio, Zig se acerca a una estructura en la que el código puede cambiar fácilmente la implementación de I/O

  • Se sientan las bases para manejar de forma unificada los modelos de I/O asíncrono según la plataforma

Próximas tareas

• Hace falta mejorar el rendimiento y reforzar las pruebas para un uso estable
• Si se agrega una función de gestión del tamaño de pila, podría usarse de forma práctica incluso en entornos donde overcommit esté desactivado
• Una vez completado, se espera que la capa de abstracción de I/O asíncrono de Zig se fortalezca aún más

Conclusión

• Esta actualización representa un avance importante en la expansión del sistema estándar de I/O de Zig
• Al integrar io_uring y GCD, se sientan las bases para asegurar una mayor consistencia del procesamiento asíncrono entre plataformas
• Cuando se complete el trabajo de estabilización, se ampliarán las posibilidades de implementar un modelo de I/O flexible y de alto rendimiento en Zig

[GN⁺]

Opiniones de Hacker News

• No soy fan de Zig, pero da gusto ver cómo un equipo pequeño progresa de forma constante
  Me impresiona su actitud de priorizar la experimentación y la mejora gradual por encima de “terminarlo” todo
  Creo que es más importante avanzar hacia metas de largo plazo que apresurarse a sacar una versión 1.0
  Para ser un proyecto tan centrado en una sola persona, es un logro sorprendente, y la gente que se esfuerza merece el reconocimiento justo

  • Cada vez que aprendo un lenguaje nuevo intento hacer un motor de juegos con servidor multijugador TCP/UDP, y hace poco lo probé con Zig
    Hasta ahora ha sido la experiencia más divertida y productiva que he tenido
    La simplicidad de Zig me encaja mucho mejor que la gestión estricta de memoria de Rust
    La vida es corta y yo solo quiero hacer software rápido y bien organizado

• En cada artículo sobre Zig hay muchas críticas, pero no entiendo por qué le dan tanta importancia
  Más bien me inspira el espíritu de ingeniería de Andrew y el equipo al intentar materializar aquello en lo que creen
  No hace falta preocuparse por si Zig se vuelve mainstream; si ayuda a resolver problemas, con eso basta
  No hay necesidad de tratar un lenguaje como si fuera una identidad

  • Para eliminar este fenómeno habría que cambiar los incentivos económicos que reciben los programadores
    Los lenguajes y las librerías son, al final, “habilidades vendibles”, así que la gente es consciente del valor de mercado de las herramientas que usa
    Además, también es un problema que quienes toman decisiones tiendan a ver a los ingenieros como recursos reemplazables
  • Estas discusiones sobre lenguajes no son algo exclusivo de Zig
    Se han repetido con Lisp, Ruby, Rust y otros, y las peleas de identidad son un problema crónico de la industria
  • Un stack de lenguaje nuevo aumenta la carga de mantenimiento en una distribución de Linux
    Hace falta gestión a largo plazo para temas de seguridad, soporte de arquitectura, etc., pero los desarrolladores suelen pasar por alto ese costo
    Zig todavía no es estable, así que hay paquetes que solo compilan en versiones concretas
    Me pregunto si realmente hace falta resolver con un lenguaje nuevo problemas que también podrían solucionarse mejorando otros lenguajes
  • Para convertirse en un lenguaje mainstream, hace falta un ecosistema de librerías predecible que cubra la mayoría de los casos de uso

• Siento que no tiene mucho sentido seguirle la pista a Zig hasta que llegue a la 1.0
  Es muy probable que la estructura actual se reescriba varias veces
  Yo también me interesé en su momento, pero no sé si llegaré a ver la 1.0 en mi vida

  • En realidad, la mayoría de las rupturas de compatibilidad en Zig ocurren en la biblioteca estándar (stdlib)
    Las funciones básicas como entrada/salida de archivos son casi iguales; lo que cambia sobre todo son los namespaces
    Yo creo que un “lenguaje vivo” es mejor
    Incluso después de la 1.x, estaría bien tener una estrategia de gestión de interfaces por versión para mantener la stdlib liviana
  • Me gusta el lenguaje Zig en sí, pero me genera dudas la calidad de la stdlib
    Como estuve construyendo mi propio framework de I/O, encontré falta de pruebas y código ensamblador incorrecto
    Lo señalé varias veces, pero no se corrigió, y eso me hizo perder confianza
  • Puede dar algo de reparo para proyectos grandes, pero Zig ya tiene valor comercial
    Sobre todo en la nube, donde optimizar el rendimiento puede reducir los costos de servidores en más de 90%
    Con Python o Node hay límites claros, y al final hay que bajar a C, C++, Rust o Zig
    De esos, Zig es fácil de aprender y cómodo de leer y probar
  • Como referencia, Bun también está hecho en Zig
    Ya es un lenguaje que se usa a nivel profesional
  • Nuestro equipo (ZML) ha estado siguiendo de cerca la rama master de Zig desde la introducción de std.Io
    La mayoría de los cambios realmente se sienten como mejoras del lenguaje

• Es interesante que Zig intente implementar esto antes, mientras que el soporte de io_uring en Rust todavía no está terminado
  En Rust es difícil diseñar abstracciones seguras y zero-cost

• Esta noticia todavía trata de una implementación incompleta
  Por ejemplo, la versión con GCD no tiene networking
  La interfaz sigue creciendo, así que se parece más a un snapshot actual que a algo terminado

  • Pero al inicio del artículo ya se aclara que está en una etapa experimental,
    y además enumera de forma concreta seis tareas principales que quedan por hacer

• Hay un issue relacionado con la optimización de memoria en stack
  Hace falta una función que permita que, aunque se use [500]u8 en bloques distintos, el stack frame ocupe solo 500 bytes
  Esto es especialmente importante en relación con los stacks de corrutinas de hilos verdes

• Veo de forma positiva el esfuerzo continuo de mejora de Zig
  Ahora mismo no hay ningún lenguaje que maneje bien io_uring
  Si Zig resuelve bien esta parte, tendría una gran ventaja
  Me parece más valiosa una actitud que prioriza el aprendizaje y la experimentación por encima de la estabilidad

  • Me parece curioso querer async incluso en lenguajes de bajo nivel
    Yo prefiero usar libxev en Zig y controlar io_uring directamente
  • Yo también soy positivo, pero me pregunto cuándo Zig sacará una versión estable de largo plazo (LTS) como C
    Uno de los factores del éxito de C fue su estabilidad y una cultura de desarrollo consistente

• Me gusta que Zig se tome en serio los targets freestanding
  Espero que en la versión 0.16 haya más reutilización de código

• Revisé el interior de macOS por primera vez en mucho tiempo, y me alegró ver que mantuvieron GCD
  Me parece un enfoque equilibrado de la paralelización

• Mientras otros lenguajes solo debaten, Zig prueba las cosas directamente y, si hace falta, da marcha atrás
  Creo que una API validada en la práctica es el mejor diseño posible
  Se pueden mantener las versiones viejas, y si te pasas a la versión más reciente obtienes herramientas más limpias y rápidas

  • Jai está más centrado en desarrollo de juegos, así que se queda corto en universalidad o seguridad
    Es complejo como C++, mientras que Zig mantiene una simplicidad a nivel de C
    Carbon todavía no tiene una forma concreta
  • Me parece raro criticar a Zig por no ser 1.0
    Jai lleva 11 años en beta cerrada, mientras que Zig ya se usa en varios proyectos reales
  • Creo que es mejor que un lenguaje tarde 20 años en quedar bien terminado
    Los cambios descontrolados que vimos con Python 2→3, async en Rust, genéricos en Go o C++ más bien han sido perjudiciales