- Ahora, para el target x86_64, el backend x86 propio de Zig se aplica por defecto en modo debug
- Logra pasar más pruebas de comportamiento y compilar más rápido que la base previa en LLVM
- La introducción del backend propio permite a Zig reducir drásticamente los tiempos de compilación y mejorar la eficiencia en algunas tareas
- También avanzan varias mejoras, como el sistema de build recientemente reforzado, la ampliación del soporte para sistemas BSD y mejoras en el runtime de UBSan
- Se destaca la competitividad propia de Zig mediante la optimización de la biblioteca estándar y sus herramientas internas
Resumen de las novedades principales más recientes
8 de junio de 2025 – el backend x86 autoalojado pasa a ser el predeterminado en modo debug
- En el target x86_64, ahora se usa por defecto el backend x86 propio de Zig
- Antes se usaba LLVM para convertir bitcode en archivos objeto
- En Windows, el cambio sigue pospuesto porque todavía hace falta más trabajo en el linker COFF
- El backend x86 de Zig pasó 1,987 pruebas de comportamiento, mostrando una estabilidad mayor que el backend LLVM (1,980)
- Hay 2,084 pruebas en total, pero algunas se superponen con pruebas propias de LLVM, por lo que solo se verifican adicionalmente al probar el backend propio
- La razón principal por la que Zig se enfoca en desarrollar su propio generador de código es superar ampliamente a LLVM en velocidad de build
- Según los benchmarks, el tiempo promedio de build de
zig build-exe hello.zig -fllvm (usando LLVM) fue de 918 ms, mientras que el backend propio registró 275 ms
- Se puede confirmar una mejora muy grande en todos los aspectos: uso de memoria, ciclos de CPU, cantidad de instrucciones, fallos de caché y más
- El tiempo de build de proyectos grandes como el propio compilador de Zig también se redujo de 75 segundos a 20 segundos
- A futuro se anticipa la implementación de paralelización completa de la generación de código, mejoras en el linking y el desarrollo del backend aarch64
- También se espera acelerar el trabajo en aarch64 con la introducción del nuevo pase Legalize
- Los cambios más recientes pueden probarse directamente mediante el último build de la rama master de Zig
6 de junio de 2025 – video de introducción al sistema de build
- Se publicó una guía en YouTube para principiantes sobre el sistema de build de Zig
- Explica cómo crear módulos y paquetes de Zig, y cómo importarlos en otros proyectos
- También está previsto que se sigan agregando más videos sobre el sistema de build como parte de una serie
20 de mayo de 2025 – se refuerza el soporte para targets FreeBSD y NetBSD
- Con la fusión de los Pull Request #23835 y #23913, ahora es posible compilar binarios para targets FreeBSD 14.0.0+ y NetBSD 10.1+ con
zig cc y zig build
- La estrategia de extraer información de libc y bibliotecas relacionadas que ya se aplicaba a glibc se extendió también a sistemas BSD
- Los archivos
abilists generados se distribuyen junto con Zig, permitiendo crear bibliotecas stub que coinciden con precisión con cada biblioteca libc durante la compilación cruzada
- También se incluyen headers del sistema y de libc basados en la versión más reciente del OS
- OpenBSD, Dragonfly BSD, SerenityOS, Android y Fuchsia también están entre los objetivos de soporte
9 de abril de 2025 – el sitio oficial de Zig ahora se construye como un Zine independiente
- El sitio web oficial de Zig ahora cambió a una estructura que se construye como un Zine independiente
- Evolucionó desde un script de build previo a un único ejecutable
- Se señala que este es un buen momento para probarlo directamente
Noticias de releases y mejoras de funciones
- La release 0.14.0 se distribuirá pronto, y ya se aplicaron varias mejoras destacables
- Con mejoras en la interoperabilidad con C y en el runtime de UBSan (Undefined Behavior Sanitizer), errores SIGILL antes ambiguos ahora fueron reemplazados por mensajes de error específicos y útiles
- Ej.: ahora se muestra claramente dónde ocurrió un overflow de entero con signo y cuál fue la causa, mejorando mucho la eficiencia de debugging
- Limitaciones restantes de UBSan:
- No hay soporte para verificaciones de tipo dinámico y ciclo de vida relacionadas con vptr en C++
- Sigue incompleta la indicación precisa de ubicación para atributos como
assume_aligned y __nonnull
7 de febrero de 2025 – innovación en el debug allocator y SmpAllocator
- El debug allocator fue rediseñado para soportar el reconocimiento del tamaño de página en runtime e incorporar varias optimizaciones
- Se redujo la creación de memory maps, se eliminó la repetición innecesaria de memset 0xaa/0x00 y se quitaron estructuras de datos de búsqueda y trip
- Los metadatos se almacenan inline dentro de la página, facilitando la implementación de errores de compilación y validación
- Frente al malloc tradicional basado en C, logra una ventaja en legibilidad y mantenibilidad
- Con el desarrollo de SmpAllocator, optimizado para entornos concurrentes, se maximizó la eficiencia de ejecución de la asignación de memoria en entornos multi-thread
- Los benchmarks comparativos con glibc demostraron en la práctica su velocidad y eficiencia en uso de recursos
- Como resultado, esto se evalúa como un punto de inflexión importante en el que la usabilidad de Zig supera a C y libc
24 de enero de 2025 – se ofrece un entorno de debugging dedicado para Zig
- Jacob desarrolló un fork de LLDB (debugger) para Zig, reforzando el soporte de debugging del backend propio
- La wiki ofrece documentación sobre cómo compilar y usar el fork de LLDB
- Los desarrolladores que usan el backend propio de Zig pueden aprovechar con esta herramienta un entorno de debugging más preciso
Conclusión
- Zig sigue impulsando cambios innovadores con el objetivo central de mejorar el rendimiento, la eficiencia de build y la comodidad del debugging sobre una base propia
- Está consolidando una competitividad diferenciada en algoritmos independientes, compilador y herramientas de build/runtime
- Incluyendo soporte para diversas plataformas como BSD, mejoras en mensajes orientados al usuario e innovación en el modelo de memoria, continúa avanzando de forma realmente útil para quienes trabajan en ingeniería de software
1 comentarios
Comentarios de Hacker News
Hasta donde sé, Zig está trabajando todos los días en varias funciones para mejorar la experiencia de desarrollo. Por ejemplo, hace poco también estuvo este PR. Antes, el hot code swapping también estaba en los planes de desarrollo de Zig, y con este ritmo de avance, supongo que probablemente será posible en x86_64 dentro de un año. Personalmente, la mayor incomodidad que siento es la velocidad de
comptime. Hubo un experimento en el que se ejecutó un DSL de brainF** en tiempo de compilación, y fue realmente lento (aunque fue un experimento divertido). Me pregunto cuándo mejorará esa parte del compilador. También tengo muchísimas ganas de ver los nuevos backends, e incluso me gustaría intentar hacer mi propio backend de URCL para Zig 😉Sobre mejorar el rendimiento de comptime, ya se sabe qué habría que hacer, e incluso hace mucho tiempo se inició una rama relacionada. Pero esto implica rehacer el código de análisis semántico a una escala significativa, así que, aunque es una de las tareas importantes, está compitiendo con otras prioridades
El hot code swapping es una función que podría cambiar por completo el desarrollo de videojuegos. Me sorprende que en Zig esté planeado soportarlo básicamente solo con una bandera del compilador. Eso es algo que con clang sería difícil incluso intentar
No he profundizado mucho en URCL, pero esto me está llevando a otra madriguera de conejo. Me hace imaginar un escenario realmente extraño en el que un IR hecho para Minecraft termine siendo un objetivo real de compilación para un lenguaje
Me pregunto si crear backends personalizados es fácil. Aún no lo he intentado personalmente, pero me gustaría experimentar con un backend que tome AIR y genere reportes de seguridad de memoria (por ejemplo, verificando uso de valores no definidos, escape del puntero de stack, use-after-free, double free, alias xor mut, etc.)
Me pregunto si el verdadero problema es que comptime sea tan lento. Estoy trabajando en una biblioteca JSON-RPC y uso comptime intensivamente en tiempo de compilación para despachar JSON a funciones arbitrarias. Como con el fuerte tipado estático de Zig no es posible despachar dinámicamente en runtime a funciones con parámetros arbitrarios, no me quedó otra que generar un mapeo de tipos de funciones en tiempo de compilación. Me preocupa que esto termine inflando inevitablemente el tamaño del binario, porque el código comptimed se copia para cada función
Ya es un logro impresionante haber llegado hasta este punto. Como se comentó en el devlog, lo que viene entusiasma aún más. La idea de que el compilador, al construir, cambie solo las partes necesarias del binario se siente fresca y rupturista, y gracias al proyecto Zig ahora se ha convertido en una meta alcanzable. Se vienen tiempos muy interesantes
La gestión de paquetes de Zig es un poco más manual que en Rust. La idea es traer directamente la URL del paquete desde la CLI e importar el módulo desde el script de build. La ventaja de este enfoque es que incluso archivos comprimidos arbitrarios pueden usarse fácilmente como dependencias, y muchos paquetes de bibliotecas C para Zig simplemente enlazan releases untouched (tarball) directamente desde el script de build. Aun así, para principiantes puede ser un poco complejo
En el caso de SDL3, hay dos opciones: un wrapper nativo de Zig (https://github.com/Gota7/zig-sdl3) y https://github.com/castholm/SDL, que básicamente zigifica la biblioteca/API de C de forma más simple
QuickJS solo soporta la API de C (https://github.com/allyourcodebase/quickjs-ng)
En Zig es muy fácil usar paquetes de C directamente, pero como los tipos son estrictos, al trabajar con la API puede que necesites hacer type casting con frecuencia
El compilador D dmd puede compilarse a sí mismo en unos 18.4 segundos en una build de depuración.
Mi procesador es un AMD Athlon 64 X2 (4400+) muy viejo, pero funciona tan rápido que ni siquiera he sentido necesidad de cambiarlo
(incluye una lista detallada de información del CPU)
Me pregunto si existe una guía para compilar Zig en solo 20 segundos para tener un ciclo de desarrollo rápido. Recuerdo que cuando intenté compilar Zig antes, había varias etapas y el bootstrap, especialmente en WASM, hacía que todo tardara muchísimo
Es impresionante que Zig pueda compilarse a sí mismo en 75 segundos incluso usando LLVM
No tengo ninguna intención de exigirle de más a Zig, y sé perfectamente que es open source, pero lo que más me interesa es un cronograma realista para el lanzamiento de 1.0.
Zig es un lenguaje de bajo nivel que contiene casi perfectamente todo lo que yo quería, y ahora solo estoy esperando a que se estabilice.
Y realmente admiro su filosofía de diseño minimalista
Como completo principiante, me pregunto cuáles son las ventajas de Zig frente a otros lenguajes. Lo entiendo como una especie de C más moderno, pero me gustaría saber qué es exactamente lo “moderno”
enum, tagged union y verificación obligatoria de exhaustividad enswitchdeferyerrdeferpara hacer limpieza automática al retornar de una función o al ocurrir un error@typeInfo, etc.) en vez de macrosGeneralPurposeAllocator(desde la perspectiva de principiante), es más fácil rastrear memory leaksNunca me sentí cómodo con C, y por muchas de sus cosas absurdas y poco intuitivas siempre sentí una barrera de entrada al low-level programming, pero Zig fue el primer lenguaje que realmente me hizo sentir diversión e interés por la programación de sistemas
Me pregunto si existe una guía para compilar Zig en 20 segundos. Quiero tener un ciclo de desarrollo rápido, pero antes sentí que no era fácil contribuir porque stage1/2/3 tardaban mucho en compilar
Si en Zig compilas hello world con
zig inity da 9.3MB, al usar la bandera-Doptimize=ReleaseSmallbaja a 7.6KBEs una diferencia de más de 1000 veces con una sola bandera
-OReleaseSmall -fno-stripda 580KB, y-ODebug -fstrippuede bajar hasta 1.4MBEl backend x86 de Zig ofrece una experiencia de depuración mucho mejor con un fork de LLDB específico para Zig
No recuerdo bien si ahora mismo se puede depurar paso a paso la lógica de comptime, pero fue un tema reciente de discusión
Creo que Julia podría considerar Zig como compilador para obtener ventajas de rendimiento. También recuerdo la ansiedad constante de los desarrolladores de Julia por posibles regresiones de rendimiento en cada release
En la práctica, Julia está fuertemente atado a LLVM. Varias partes del ecosistema dependen de cosas como intrinsics de LLVM, autodiff (Enzyme) y compilación para GPU.
El compilador se está volviendo bastante retargeteable, y esa parte también está siendo investigada activamente.
A futuro, incluso podría imaginarse un escenario donde Zig sea un compilador alternativo para partes del lenguaje
Hay quien opina que LLVM en sí es la API pública de Julia. De hecho, existen macros como @code_llvm que muestran directamente el IR
Sin duda ayudaría a reducir los tiempos de compilación, pero del lado de Julia todavía hay mucho por hacer
Está el tema de granular más el caché de compilación, herramientas para evitar invalidation, eliminar optimizaciones de world splitting, aumentar el uso de multithreading en el compilador, precompilar automáticamente ciertas signatures y también compilar código lazily o hacer hot swap
Esto es un avance enorme para Zig, y creo que será una de sus principales formas de diferenciarse frente a Rust en adelante. Como dato, yo mismo escribí gran parte del código de renderizado de una herramienta de análisis de rendimiento, y me alegra ver que mi código se use ampliamente en línea
enlace al proyecto poop
Ver rustc_codegen_cranelift
Creo que esta es justamente una de las precondiciones para volver a introducir async/await en Zig
También vale la pena revisar el FAQ oficial de Zig sobre async
Esa parte ya está completamente encaminada, y probablemente en los próximos 2 o 3 meses podremos compartir actualizaciones interesantes. Prácticamente estamos rehaciendo todo el I/O, casi como si estuviéramos reconstruyendo la biblioteca estándar
Según el enlace, parece que async podría no volver nunca, o al menos no habría que esperarlo antes de 2028 como mínimo