Zig lleva más de una década sin llegar a 1.0
Zig es uno de los lenguajes de programación de sistemas más interesantes de la última década y, al mismo tiempo, cada vez más difícil de recomendar. Lleva más de diez años en desarrollo y sigue en la versión 0.x, sin una fecha firme para su 1.0. Para un equipo que decide en qué stack construir su producto, eso no es un detalle: es una variable de riesgo.
Un análisis publicado por bytecode.news sostiene que el problema de Zig no es técnico, sino de gestión. El texto repasa una serie de decisiones —rupturas de compatibilidad, una política de contribución muy restrictiva, la salida de su usuario más visible y un cambio de plataforma de desarrollo— que, vistas juntas, dibujan un patrón preocupante.
¿Por qué Zig rompe compatibilidad en cada versión?
Un lenguaje de programación es infraestructura. Los equipos escriben aplicaciones y librerías contra su sintaxis, su librería estándar, su compilador y su sistema de build. Cuando esas interfaces cambian, el ecosistema entero paga la cuenta.
Antes de levantar capital, que el negocio sea rentable
Quien invierte mira primero si el negocio vende y deja margen. Para llegar ahí con menos horas encima, el Kit «tu mano derecha con IA» te da un video de 11 minutos y una ficha para dejar a un agente de IA trabajando en tu negocio. CAR está cerrada por ahora.
👥 Quiero el Kit →Según el análisis, las notas de la versión 0.15.1 introdujeron cambios sustanciales en las interfaces de I/O y en la librería estándar, incluido el episodio que la comunidad bautizó como Writergate. La 0.16 continuó esa transición y la 0.17.0, publicada en octubre de 2026, sumó más cambios al lenguaje y a sus herramientas.
El resultado práctico: actualizar Zig rara vez es instalar un compilador nuevo. Suele implicar reescribir partes del código, actualizar dependencias y esperar a que las librerías se pongan al día. El proyecto mantiene un roadmap hacia 1.0, pero no da indicios concretos de cuándo dejarán de moverse las interfaces de las que dependen los desarrolladores.
Para ponerlo en perspectiva: Go publicó su 1.0 en marzo de 2012, unos dos años y medio después de su debut público en 2009, y Rust llegó a 1.0 en mayo de 2015, alrededor de cinco años después de su desarrollo público inicial. Zig, con más de una década encima, sigue sin esa referencia.
La política anti-IA que juzga al contribuidor, no al código
Zig tiene una de las políticas de contribución con IA más restrictivas del open source: nada de código generado por IA, nada de edición asistida, nada de traducción asistida, ni siquiera usar un LLM para buscar bugs.
Los mantenedores explican su filosofía en un texto citado por el análisis, Contributor Poker and Zig’s AI Ban, con una frase que resume su postura: «You play the person, not the cards». La idea es que conviene invertir en contribuidores que desarrollen un conocimiento profundo de Zig y se queden a largo plazo, y que revisar pull requests de baja calidad es caro.
El punto discutible, según el análisis, es que una contribución útil puede rechazarse no porque sea incorrecta o difícil de mantener, sino porque su autor usó las herramientas equivocadas. El proyecto deja de evaluar el aporte y empieza a evaluar el proceso de desarrollo de quien lo hizo.
Bun se fue a Rust y la respuesta de Zig generó ruido
Durante años, Bun —un runtime de JavaScript de alto rendimiento escrito en Zig— fue publicidad gratuita para el lenguaje. En julio de 2026, Bun anunció que había reescrito su base de código en Rust.
Sus razones, según el análisis, fueron técnicas: problemas recurrentes de seguridad de memoria, sobre todo en la interacción entre el recolector de basura de JavaScript y la gestión manual de memoria de Zig. El sistema de ownership de Rust ofrecía garantías que Bun necesitaba para su carga de trabajo. Además, Bun mantenía sus propias modificaciones al compilador de Zig, lo que sumaba carga de mantenimiento.
La respuesta de la cúpula de Zig, según el mismo texto, fue un ataque público extenso que cuestionó las prácticas de ingeniería, la gestión, la cultura de desarrollo y las decisiones de negocio de Bun, y que describió a la fundación como aliviada por el final de la relación. La publicación se revisó después y reconoció resentimiento en su enfoque inicial.
Para cualquier equipo que dependa de una tecnología open source, la señal es incómoda: si un usuario grande recibe ese trato al irse, ¿qué puede esperar uno pequeño que critica o decide migrar?
Codeberg: cambiar GitHub por un proveedor menos probado
En noviembre de 2025, Zig anunció su migración de GitHub a Codeberg, un servicio de hosting Git sin fines de lucro basado en Forgejo. El análisis considera legítimas las críticas a GitHub Actions, pero cuestiona el destino elegido por problemas de fiabilidad.
No es un movimiento aislado. Gentoo también está migrando a Codeberg, según reportó XDA Developers, en su caso para evitar el escaneo de código y el entrenamiento de IA sobre sus repositorios en GitHub. Linux Journal describe el fenómeno como una tendencia más amplia en el open source, con proyectos explorando alternativas como Codeberg, SourceHut o instancias propias de Forgejo.
El punto que plantea el análisis es otro: en julio de 2026, Codeberg publicó Protecting our FLOSS commons from LLMs, donde restringe ciertas categorías de proyectos intensivos en IA y sostiene que los LLM son incompatibles con el desarrollo open source responsable. Un proveedor de hosting que decide qué formas de desarrollo son legítimas es, como mínimo, un riesgo nuevo para quien aloja ahí su infraestructura crítica.
¿GitHub Sponsors como pasivo? El mensaje a los donantes
En el mismo anuncio de la migración, los mantenedores escribieron que, aunque GitHub Sponsors representa una fracción importante de los ingresos por donaciones de la Zig Software Foundation, lo consideran «a liability» (un pasivo). Pidieron a los seguidores mover sus donaciones recurrentes a Every.org y retiraron los beneficios de GitHub Sponsors.
El análisis señala la contradicción: si el proyecto se financia en buena parte con donaciones voluntarias, hacer más incómodo donar debería exigir una explicación mejor que no gustar de la plataforma. Una alternativa razonable habría sido dejar el repositorio en GitHub como espejo de solo lectura y mantener ambos canales de donación abiertos.
¿Qué significa esto para tu startup?
Zig no está muerto y su compilador sigue mejorando. Pero la lección para un founder no es sobre Zig en particular, sino sobre cómo evaluar cualquier dependencia tecnológica.
- Mide el costo de la inestabilidad antes de adoptar. Si eliges una herramienta en versión 0.x para producción, fija la versión del compilador, documenta qué APIs usas y reserva horas de ingeniería por cada release. Un lenguaje que rompe compatibilidad cada pocos meses es un costo recurrente, no un evento único.
- Haz due diligence de gobernanza, no solo de features. Antes de comprometerte con una tecnología open source, revisa el roadmap, la política de contribución, el historial de breaking changes y cómo trata el proyecto a quienes se van. La gobernanza predice el soporte a largo plazo mejor que cualquier benchmark.
- Diversifica tu infraestructura crítica. El caso de Zig y Codeberg aplica a cualquier proveedor: si tu CI, tu hosting o tu facturación dependen de una sola plataforma, ten un plan de salida documentado. Migrar por convicción es válido; migrar sin plan B no.
- Cuida el costo humano de las migraciones. Cada ruptura de compatibilidad consume tiempo de tu equipo que no se dedica al producto. Ese es el argumento más fuerte para preferir tecnología aburrida y estable en el núcleo de tu negocio.
Conclusión
El análisis de bytecode.news no dice que Zig sea un mal lenguaje: dice que su gestión está alejando a quienes quieren usarlo. Un proyecto puede mantener sus ambiciones técnicas y, a la vez, volverse más confiable; para eso necesita tratar las necesidades de sus usuarios como un requisito y no como una molestia.
Mientras eso no cambie, la decisión para un equipo es simple: adoptar Zig como apuesta experimental, con los costos de migración presupuestados, o elegir un stack con interfaces estables. Lo que no conviene es asumir que la madurez técnica llegará sola.
Fuentes
- The Zig project is going nowhere (fuente original)
- Gentoo begins its exodus from GitHub as it settles into Codeberg
- Gentoo Charts a New Path: Moving Away from GitHub Toward Codeberg
Antes de levantar capital, que el negocio sea rentable
Quien invierte mira primero si el negocio vende y deja margen. Para llegar ahí con menos horas encima, el Kit «tu mano derecha con IA» te da un video de 11 minutos y una ficha para dejar a un agente de IA trabajando en tu negocio. CAR está cerrada por ahora.
👥 Quiero el Kit →
