Zig: qué deja tras 4 meses de uso frente a Rust

Zig: qué deja tras cuatro meses de uso frente a Rust

Cuatro meses, tres proyectos y un veredicto: después de años escribiendo Rust, un desarrollador volvió a Zig y concluye que no encontró otro lenguaje que prefiera más, incluso con sus carencias. Su recuento, publicado en su blog personal, funciona como una radiografía honesta para cualquier equipo que esté evaluando un lenguaje joven para producción.

El primer proyecto fue snurl, una librería para interactuar con la "smallnet" (Gemini, Finger, Gopher y Spartan), pensada como alternativa a curl para ese ecosistema, con requisitos de testing y fuzzing similares aunque a menor escala. Luego llegaron dos programas todavía sin publicar: un "typer racer" en TUI y un simulador de n cuerpos con evolución estelar construido con raylib.

Un detalle del arranque vale como advertencia: el fuzzer de Zig no funcionaba. La funcionalidad no estaba terminada, pese a que aparece demostrada en el archivo main.zig que genera zig init. Es exactamente el tipo de sorpresa que aparece a mitad de camino cuando se asume que lo que muestra la herramienta ya está listo.

¿Por qué un Zig Day importa más de lo que parece?

El hito personal de estos meses fue un Zig Day en Seattle: el autor se enteró del evento en Lobsters y participó el 20 de agosto, con Andrew Kelley, el creador del lenguaje, entre los asistentes. El encuentro se trasladó de la biblioteca de Bellevue a la de Bothell porque las inscripciones desbordaron la capacidad original.

Los Zig Days son meetups locales donde la gente trabaja en sus proyectos y conversa sobre el lenguaje. Un amigo, Evin Yulo, también asistió: ambos trabajaron sobre snurl y Evin empezó a integrar la implementación TLS de la librería estándar de Zig como backend alternativo. Para una startup, ese formato tiene una lectura práctica: es donde se consigue talento con experiencia real en el lenguaje y donde se resuelven dudas que la documentación no contesta.

¿Qué funciona bien en Zig según quien lo usa todos los días?

Allocators explícitos. Cada función que asigna memoria debe recibir un parámetro de allocator. Eso permite usar un arena allocator para una parte del código y un general purpose allocator para otra, o resolver una operación con un FixedBufferAllocator. El autor lo compara con el contexto implícito de Odin (que prefiere evitar) y con las asignaciones ocultas de Rust, que pueden entrar en pánico cuando la memoria se agota. Su conclusión: es mucho más fácil razonar sobre un programa que asigna memoria de forma explícita.

El parámetro IO. Cada función que interactúa con el sistema operativo, con matices, requiere un parámetro IO. Eso da contexto de entrada, salida y todo lo demás, y hace que portar Zig a un sistema operativo nuevo sea, en esencia, portar IO. En testing el beneficio es directo: se inyecta una instancia de IO de prueba, se cambia el stream de entrada a voluntad y se pueden forzar fallos de escritura.

Comptime, el build system y la cultura de dependencias. El autor describe comptime como una vía fluida para metaprogramación y precomputación, y el build system como "estelar": compañías como Uber lo adoptaron para software escrito en otros lenguajes, y permite integrar herramientas externas donde Cargo se resiste, algo clave para proyectos con generación de código.

En dependencias, el criterio es simple: evitar. Cuando hace falta una, suele ser una librería probada que se integra vía translate-c, y se puede vendorizar para auditarla. La mayoría de sus programas en Zig tienen una o dos dependencias directas y cero indirectas, contra las docenas de indirectas que arrastran sus proyectos más pequeños en Rust. Parte de la razón es que reflexión, generación de números aleatorios, manejo de errores y parseo de JSON vienen en el lenguaje o en la librería estándar, sin necesidad de sumar serde o syn en cada programa.

Errores e incrementalidad. Zig empuja a manejar errores por defecto: el camino más perezoso es try y agregar ! al tipo de retorno. En Rust, sostiene, es más fácil terminar dejando panics en el código, y hacerlo bien exige escribir algo como Result<Type, Box<dyn std::error::Error>> o sumar una dependencia como anyhow. Además, con zig build --watch -fincremental el compilador detecta qué cambió y recompila solo eso hasta el enlazado, algo que describe como más rápido que la percepción humana. Hoy está disponible solo en x86_64 sobre Linux y macOS. En proyectos Rust, ciclos de compilación incremental de más de diez segundos eran comunes incluso en proyectos chicos: tiempo suficiente para distraerse, insuficiente para avanzar en otra cosa.

¿Dónde se queda corto Zig?

• Estabilidad. El autor pide una librería estándar más estable y reconoce que la rotura constante del ecosistema es frustrante; su lectura es que esa es la razón por la que 0.17.0 tardó tanto en salir. Es el único motivo por el que todavía usa Rust en algunos proyectos. Kelley dijo en el Zig Day que quiere ver el 1.0 más que nadie.
• Documentación. Es escasa: alcanza para empezar, pero para seguir hay que interpretar comentarios sueltos y hay pocos ejemplos. El propio autor todavía no logra que el TLS de la librería estándar funcione en snurl, ni él ni un amigo pudieron configurar los buffers correctamente.
• Lifetimes. Quiere que devolver variables locales falle en modo debug, porque hoy es fácil romper el código sin querer. También señala que el compilador acepta código que se romperá en el futuro: deja vivir a las variables todo el scope en lugar del bloque.
• Allocators en comptime. No se puede parsear JSON en tiempo de compilación porque el parser de la librería estándar exige un allocator.
• Bootstrapping y distribución. Zig se bota con un blob WASM compilado que se guarda en el código fuente. Es mejor que exigir el compilador anterior completo, pero deja margen a que alguien introduzca algo malicioso en el blob, y hace imposible empaquetarlo conforme a las reglas de distribuciones como Debian. Por eso el autor eligió otro lenguaje para uno de sus proyectos.

¿Qué significa esto para tu startup?

Zig no es una apuesta de producto: es una apuesta de infraestructura. La lectura útil para un equipo chico es separar dónde el lenguaje suma y dónde te expone.

• Úsalo donde la ventaja es concreta. Herramientas internas, CLIs, utilidades de infraestructura y todo lo que se beneficie de binarios únicos y compilación cruzada. Para el camino crítico de un producto que necesita estabilidad de años, el propio autor sigue eligiendo Rust.
• Copia el criterio de dependencias. Una o dos dependencias directas y cero indirectas no es una excentricidad: es un árbol que puedes auditar en una tarde y que reduce el riesgo de cadena de suministro. Aplícalo también en tus proyectos actuales, aunque no uses Zig.
• Diseña para testear con IO inyectable. El patrón de pasar allocator e IO como parámetros convierte el testing de comportamiento en algo trivial, porque puedes forzar fallos de escritura o cambiar la entrada sin tocar el código de producción.
• Verifica la funcionalidad antes de comprometerte. El caso del fuzzer es el ejemplo: la función estaba anunciada en la plantilla generada pero no terminada. Antes de adoptar un lenguaje joven, prueba la feature exacta que tu proyecto necesita, no la que aparece en el tutorial.
• Revisa la distribución. Si tu producto debe instalarse desde repositorios de distribuciones como Debian, hoy Zig no se puede empaquetar conforme a sus reglas.
• Ve a los meetups. Los Zig Days son un canal de talento y de conocimiento no escrito, y el propio autor los describe como la forma de sentirse parte de una comunidad interconectada.

Conclusión

Zig ofrece un modelo de memoria y de IO que obliga a ser explícito, un build system que ya convenció a compañías grandes y una cultura de dependencias que muchos equipos deberían imitar. Lo que falta, estabilidad, documentación y empaquetado, es justamente lo que traerá el 1.0. Para una startup, la decisión razonable no es "Zig sí o no", sino dónde sí y dónde todavía no. No se encontraron datos adicionales verificables en la búsqueda complementaria: este análisis se apoya en el testimonio del autor.

Fuentes

• Four Months of Zig (fuente original)