Volver a Zig - Zig → Rust → Zig

• Zig comenzó como un lenguaje de bajo nivel que buscaba reducir las incomodidades de C, y volvió a convertirse en un lenguaje que vale la pena reconsiderar por su filosofía de asignación explícita de memoria y ausencia de flujo de control oculto
• Rust fue una alternativa práctica para salir de los cambios frecuentes de Zig y de su ecosistema inmaduro, pero mostró límites en puntos como FFI, compilación cruzada y asignaciones ocultas
• En la decisión de volver a Zig influyeron no solo razones técnicas, sino también una pérdida de confianza en el proyecto Rust en torno a su gobernanza y a la política sobre código generado por LLM
• El Zig de 2026 sigue siendo inestable y Zig 0.17.0 romperá el sistema de build, pero la sensación del lenguaje no es muy distinta a la de 2020 y la experiencia de gestión de paquetes ha mejorado
• Zig no ofrece seguridad de memoria en tiempo de compilación al estilo de Rust, pero en su lugar elige un equilibrio entre simplicidad y seguridad en tiempo de ejecución mediante ReleaseSafe, tests, fuzzing y una filosofía basada en assert

---

El punto de partida de lo que me atrajo de Zig

• Conocí Zig por primera vez en 2020, y en ese momento parecía un lenguaje nuevo y pequeño con ejecución de código en tiempo de compilación y abstracciones simples
• Aprender C daba una buena sensación de controlar directamente la computadora, pero sus abstracciones antiguas y sus herramientas limitadas resultaban incómodas
• Aunque era nuevo e inestable, Zig prometía ser un lenguaje de reemplazo para C, y resultaba atractivo poder aprender “el siguiente lenguaje”
• Software Should Be Perfect de Andrew Kelley me dio un criterio para pensar los lenguajes de programación y el software
  • asignación explícita de memoria con posibilidad de fallo
  • ausencia de flujo de control oculto
  • reutilización universal
• Al crear con Zig un lenguaje de programación de juguete, una herramienta de literate programming y un servidor web, sentí que era un lenguaje más cómodo que C pero con menos elementos peligrosos

Por qué me pasé a Rust

• Zig rompía el código con frecuencia, y como estudiante no tenía tiempo para seguir corrigiendo proyectos cada vez para adaptarlos a la versión más reciente del lenguaje
• En ese momento no existía anyzig, así que no era fácil manejar varias versiones de Zig en un mismo sistema
• A veces, tras volver a un proyecto después de unos meses, había que hacer un gran refactor que no entendía del todo solo para que volviera a funcionar
• El ecosistema también seguía siendo pequeño
  • como programador nuevo, no tenía la capacidad de implementar por mi cuenta todo lo que necesitaba
  • había pocas librerías y pocos ejemplos
  • la librería estándar seguía cambiando
  • incluso la documentación básica era inestable
• Rust ya llevaba años estabilizado y era un lenguaje con un ecosistema sólido
• Aprender Rust fue difícil, pero una vez dominado el código funcionaba de forma estable, y esa estabilidad era importante
• Era un lenguaje rápido y de bajo nivel, pero con la expresividad necesaria, y además reducía el costo de la inestabilidad que sufría en Zig
• Rust también ayudó a formar un modelo mental de memoria útil incluso al usar lenguajes con menos verificaciones integradas
• En código sin panic era posible escribir código reutilizable sin flujo de control oculto ni recolector de basura
• Aun así, Rust tendía a ocultar la asignación de memoria y a dificultar el trabajo con C

Las molestias que me hicieron volver a mirar Zig

• Rust no era el lenguaje perfecto para crear los programas reutilizables que quería
  • FFI es difícil
  • la compilación cruzada es engorrosa
  • las asignaciones de memoria ocultas, tratadas como si no pudieran fallar, son una carga
  • al estar atado a LLVM, puede tardar mucho o ser imposible soportar tantas plataformas como C
• La gobernanza también seguía siendo un punto incómodo
  • la Rust Foundation tiene varias grandes empresas entre sus foundation members
  • si las empresas más grandes del mundo aportan cientos de miles de dólares al año, considero posible que eso influya en la dirección del desarrollo de Rust
• También fue impactante ver que en la comunidad open source cada vez más proyectos aceptaban código generado por LLM
• En varios proyectos, mantenedores y usuarios redactaron o exigieron políticas sobre LLM
• Zig prohibió por completo el uso de LLM en el proyecto
• Rust hizo una encuesta y el sentir general de la comunidad era anti-LLM, pero no creó de inmediato una política oficial
• La propuesta de política de Rust incluía una cláusula que impedía mencionar en los comentarios de PR los siguientes temas
  • el impacto social y económico de largo plazo de los LLM
  • el impacto ambiental de los LLM
  • el estado de copyright de los resultados generados por LLM
  • los juicios morales sobre quienes usan LLM
• Esa cláusula fue eliminada tras la reacción en contra, pero el simple hecho de que hubiera estado allí redujo mi confianza en el proyecto Rust
• La política en sí me parecía en su mayor parte aceptable, ya que limitaba el uso de LLM y reducía el slop
• Esa experiencia fue lo que me llevó a volver a mirar Zig seriamente por primera vez en varios años

Zig en 2026

• Zig sigue siendo inestable
• Intenté empezar con ejemplos de Zig 0.16.0 encontrados en la web, pero ya estaban desactualizados
• Para trabajar productivamente con Zig, lo mejor es tener a mano una copia del código fuente de la librería estándar y familiarizarse con ella
• Zig 0.17.0 será lanzado pronto y romperá el sistema de build de todos los proyectos
• Los mantenedores están intentando avanzar hacia la estabilización, y este tipo de ruptura es parte de ese proceso
• Por suerte, el lenguaje en sí no ha cambiado demasiado desde 2020
  • la mayoría de mis intuiciones seguían funcionando
  • algunas partes de las librerías fueron rehechas, pero el código seguía siendo fácil de leer
  • creo que el código Zig actual seguirá siendo reconocible dentro de 6 años
• Ahora Zig tiene gestor de paquetes
  • recuerdo que antes usaba git submodule para manejar dependencias
  • la herramienta integrada es mucho mejor
  • los proyectos pueden definir dependencias con git y tarball
  • el vendoring funciona fácilmente
• El ecosistema sigue sin ser enorme, pero Zig tampoco apuntaba a tener un ecosistema gigantesco
• No hay un registro oficial de paquetes, y la postura es que no hace falta otro NPM o crates.io
• En este momento, Zig parece haber encontrado un equilibrio adecuado

Cómo veo la seguridad de memoria

• Zig no ofrece las mismas garantías de seguridad de memoria que Rust
• Eso es un trade-off en favor de la simplicidad, y no considero que la complejidad de los tipos afines de Rust valga tanto como la ganancia de seguridad
• Eso no significa que Zig haya renunciado a la seguridad
• Desde la perspectiva de Zig is safer than unsafe Rust, Zig puede ser una mejor opción en situaciones donde habría que usar unsafe Rust
• Zig también sigue trabajando para hacer el lenguaje más seguro
  • su enfoque no se centra en zonas de código unsafe, sino en el modo release
  • actualmente, el modo ReleaseSafe de Zig hace crash si falla un assertion e inicializa toda la memoria
  • Andrew Kelley está interesado en llevar ReleaseSafe hacia algo que incluya herramientas como Fil-C
• Este enfoque no ofrece la seguridad de memoria en tiempo de compilación de Rust cuando se evita unsafe, pero tampoco creo que sea la espiral de muerte que algunos describen
• La seguridad de memoria es un espectro, y no existe un único enfoque mejor para todas las situaciones
• El enfoque de Zig consiste en hacer que ReleaseSafe sea lo más seguro posible en tiempo de ejecución y verificar la corrección mediante tests y fuzzing
• Los comportamientos ilegales no verificados deben encontrarse en ese proceso, y una vez demostrada la corrección, considero que se pueden distribuir de forma segura binarios con otros modos de release
• Este enfoque tiene desventajas frente al modelo de Rust, pero no lo considero estrictamente inferior dentro de la fuerte apuesta de Zig por la simplicidad
• Si la seguridad de memoria en tiempo de compilación es lo bastante importante como para justificar el costo de un sistema de tipos complejo y tiempos de compilación largos, entonces se puede elegir Rust
• El modelo de seguridad de memoria de Zig también se extiende a su filosofía sobre los assertion
  • en vez de desactivar los assertion en ReleaseFast, se confía en que mediante tests se demostró que esos assertion son correctos y que esa ruta es unreachable
  • eso permite a Zig optimizar el código
  • un texto relacionado es your assertions are correct

Cómo pienso usarlo a futuro

• Estoy listo para abordar problemas de software con Zig, manteniendo cerca la librería estándar y el registro de cambios de cada release
• Cuando no quiera lidiar con detalles de bajo nivel, planeo usar mi lenguaje de scripting preferido
• Mi plan es usar Zig como herramienta central en mi software de ahora en adelante
• También dejo abierta la posibilidad de no quedarme en Zig para siempre
  • si necesito la estabilidad o el sistema de tipos de Rust, puedo usar Rust
  • puede que mi forma de pensar sobre el enfoque de Zig cambie por completo
  • varios lenguajes pueden coexistir y deberían coexistir
• Zig representa una visión del software centrada en el usuario al aceptar el software sin ignorar la calidad
• La gente merece recibir software confiable y potente, y considero que en la era de los LLM el software hecho con cuidado se vuelve más raro, mientras se presiona a las personas para aceptar un slop cada vez peor

[clastneo]

Durante mi aprendizaje de Zig, vi que se hablaba de que saldría una nueva versión y terminé abandonando el estudio.
Cuando salga una versión estable, quizá valga la pena volver a ponerlo en mi lista de aprendizaje, pero por ahora los cambios incompatibles son tan grandes que me da miedo meterle mano.

[click]

Zig sigue cambiando la especificación del lenguaje y descartando la compatibilidad hacia atrás, así que creo que, como mínimo hasta que salga la versión 1.0, es difícil usarlo en sistemas importantes.
Parece que ghostty está sufriendo bastante por el cambio en std.IO: issue
Por tomar un ejemplo de otro lenguaje: si en Java, después de que salió Future, la API de JDBC hubiera cambiado para devolver Future o CompletableFuture, sin duda habría sido un gran avance, pero a cambio habría creado una confusión enorme.

[GN⁺]

Opiniones en Lobste.rs

• En algún momento me gustaría volver a probar Zig
  De verdad quiero hacerlo, pero hasta ahora he estado ocupado con otras cosas
  La última vez que toqué Zig me topé con un error del compilador después de unas 3 horas y me dejó bastante impresión. Siendo justos, ese bug ya estaba corregido en la rama más reciente

• Me genera dudas la idea de que “como está atado a LLVM, tardará muchísimo o quizá nunca podrá soportar tantas plataformas como C”
  Me pregunto qué plataforma que LLVM no soporta querrían usar como objetivo, y en qué sentido Zig sería mejor en ese aspecto
  Quisiera preguntar si eso significa que Zig genera código C tier-4 y que luego GCC puede compilarlo para hppa, alpha y sh

  • Según entendí, iba más por el lado de que Zig está trabajando activamente para reducir su dependencia de LLVM, así que en el futuro quizá no haga falta tocar el proyecto LLVM en sí para implementar nuevos objetivos en el compilador de Zig
  • Por ahora, la implementación de eso es la generación de código C
    El punto es que Zig tiene un backend oficial aparte de LLVM, mientras que Rust usa LLVM
    Si es un lenguaje de sistemas que busca maximizar la reutilización del software, debería poder ejecutarse en la mayor cantidad posible de entornos, y más aún si, como Zig, busca reemplazar a C
  • Si mal no recuerdo, la preocupación estaba más enfocada en los tiempos de compilación que en el soporte de plataformas

• Viendo el éxito de ghostty, cuando Zig llegue a la 1.0 pienso probarlo para desarrollo de videojuegos
  Aunque no estoy muy seguro de si el tipo de juegos que hago realmente necesita ese nivel de rendimiento

  • Si conoces Godot, puedes probar https://github.com/godot-zig/godot-zig

• Es bastante común ver comentarios del tipo “Zig no renunció a la seguridad, y es más seguro que Rust con unsafe. Si de todos modos vas a tener que usar unsafe Rust, entonces Zig puede ser mejor”, pero cada vez que los veo no termino de entenderlos
  Sobre todo porque, aunque el autor reconoce que la seguridad es un espectro, igual recomienda cambiar a un lenguaje donde todo sigue siendo unsafe, en vez de usar zonas unsafe localizadas
  Puede que la máquina abstracta sea un poco más fácil de razonar, pero ese intercambio no me termina de convencer