Zig 0.17 vs C: qué cambia al escribir código de sistemas

El código C escrito en 1990 sigue compilando hoy sin cambios; el código Zig de hace dos años, no. Esa asimetría es el punto de partida de un análisis recién publicado por un ingeniero de sistemas que, después de años escribiendo C —su lenguaje favorito, admite—, decidió dejar de usarlo para código nuevo. Su tesis no es que C sea malo: es que hay partes de C que cuestan tiempo, y que Zig las resuelve sin obligarte a cambiar de modelo mental.

Para un founder técnico la pregunta importa por una razón concreta: cada lenguaje que sumas al stack es deuda de contratación y de mantenimiento. Elegir mal la capa de sistemas se paga dos veces, primero en bugs difíciles de rastrear y después en reescrituras.

¿Por qué C sigue siendo el piso sobre el que corre todo?

C es el lenguaje de UNIX. Los kernels, las bibliotecas C y casi todas las bibliotecas de sistema que terminan llamando los demás lenguajes están escritas en C, y las páginas de manual las documentan con prototipos y ejemplos en C. Un programa de los años noventa compila hoy, y existe un compilador de C para casi cualquier CPU que se haya fabricado. El lenguaje es tan pequeño que un solo libro —The C Programming Language, de Kernighan y Ritchie— lo cubre entero.

¿Y esto cómo se aplica en tu negocio?

Dueños de negocio de Latinoamérica y España usan un agente de IA para ganar más y recuperar su tiempo. El Kit «tu mano derecha con IA» te muestra cómo en un video de 11 minutos, con una ficha para armar el tuyo. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

Zig no intenta reemplazar nada de eso. Habla con las bibliotecas C directamente y usa la ABI de C cuando hace falta. Esa decisión de diseño es la que hace viable la convivencia: no hay que elegir entre los dos mundos.

El contexto que empuja el cambio es de política, no de gusto. Un análisis comparativo publicado en octubre de 2026 recuerda que Microsoft y el equipo de Chromium de Google encontraron que alrededor del 70% de sus vulnerabilidades graves de seguridad provienen de errores de manejo de memoria, que en 2024 la Casa Blanca pidió adoptar lenguajes con memoria segura y que CISA y el FBI solicitaron hojas de ruta al respecto para finales de 2025. El mismo análisis cita el caso de Android: al mover código nuevo a Rust, los bugs de seguridad de memoria pasaron del 76% de sus vulnerabilidades en 2019 a menos del 20% en 2025.

Conviene ser preciso: Zig no es un lenguaje de memoria segura como Rust. No impide que uses memoria después de liberarla. Lo que ofrece es otra cosa: un C mejor, con verificaciones en los modos de depuración y sin flujo de control oculto.

¿Cómo se libera memoria sin goto?

El código C que el autor dice que menos le gusta es una función que adquiere varios recursos y debe liberarlos en orden inverso cuando algo falla a mitad de camino. La respuesta habitual, la misma que usa el kernel de Linux, es goto con etiquetas de limpieza. Funciona, pero la limpieza queda lejos de la reserva y el orden de las etiquetas tiene que coincidir a mano con el orden de las asignaciones.

En Zig cada errdefer se escribe justo debajo de la asignación que deshace, y solo se ejecuta si la función devuelve un error. Zig los corre en orden inverso, así que no hay etiquetas que mantener alineadas.

Lo más útil para un equipo no es la sintaxis, sino que cada camino de fallo se puede testear. El tipo std.testing.FailingAllocator falla en la primera, la segunda o la tercera asignación según el valor de fail_index, y el allocator de testing reporta la memoria que no se liberó. En C, probar esos mismos tres caminos exige envolver malloc() o usar una herramienta externa.

¿Qué errores de C deja pasar Zig?

Tres ejemplos del artículo valen para explicar la diferencia.

Los slices conocen su longitud. En C, un array que entra a una función se convierte en puntero y el largo viaja aparte, si es que viaja. Un <= en lugar de < en un bucle de suma devuelve un resultado incorrecto —el autor lo corrió y obtuvo sum = 7 con un array de tres elementos— sin que ni clang -Wall -Wextra ni el propio programa se quejen. En Zig el slice lleva su longitud y el mismo error detiene el programa en los modos debug y safe. Los strings funcionan igual: son slices de bytes con largo, así que no hay strlen() recorriendo memoria ni buffers a los que les falta el terminador.

Los errores no se pueden ignorar. En C una función reporta el fallo devolviendo -1 o NULL y nada te obliga a mirar. En Zig el error es parte del tipo de retorno y el compilador se niega a compilar una llamada cuyo error ignores: hay que usar try, catch o if.

Menos sorpresas indefinidas. El desbordamiento de un entero con signo es comportamiento indefinido en C: el estándar permite al compilador hacer cualquier cosa, incluso eliminar código que decide que nunca puede ejecutarse. En Zig el desbordamiento se verifica en debug y safe, y el programa se detiene con panic: integer overflow y la línea exacta. Cuando quieres el comportamiento envolvente escribes +%, y cuando quieres que el resultado se quede en el máximo, +|.

A eso se suma comptime: el código que corre en tiempo de compilación es Zig común, así que en lugar de #ifdef __linux__ escribes if (builtin.os.tag == .linux) y el compilador descarta la rama que no aplica. Los tipos son ciudadanos de primera clase en tiempo de compilación, y de ahí salen los genéricos.

Zig también es un compilador de C

Esta es la parte que más rápido se puede aprovechar. El comando zig cc es un compilador de C que reemplaza a gcc o clang, y cross-compila sin instalar nada extra: zig cc -target x86_64-linux-musl -o sum sum.c genera un ejecutable estático para Linux desde una Mac. En modo debug, zig cc además activa el sanitizador de comportamiento indefinido.

Un archivo build.zig puede compilar archivos C junto a archivos Zig, así que un proyecto C se puede mover a Zig de a un archivo por vez manteniendo el mismo build. Ojo con un detalle de versión: en Zig 0.17 el builtin @cImport() ya no está y la traducción de C se hace con zig translate-c.

¿Cuánto cuesta adoptar Zig hoy?

El propio autor marca los límites. Zig no te salva de usar memoria después de liberarla ni de guardar un puntero a una variable de stack que ya no existe. En los modos fast y small la mayoría de las verificaciones se apagan y vuelves al comportamiento indefinido, igual que en C.

Y está la estabilidad. Cuando salió Zig 0.17, el autor tuvo que cambiar 35 de los 152 archivos Zig de su libro. El código C de hace décadas sigue compilando. C tiene más herramientas, más libros, más gente que lo conoce y compiladores para chips que Zig no soporta: si escribes para un microcontrolador que solo tiene el compilador del fabricante, la decisión ya está tomada.

Del otro lado, el respaldo de la industria creció. Synadia y TigerBeetle comprometieron en conjunto US$512K a la Zig Software Foundation a lo largo de dos años, según el anuncio difundido en octubre de 2025, y ese comunicado menciona a TigerBeetle, Bun y Ghostty como proyectos que ya usan el lenguaje en producción. En la encuesta de Stack Overflow de 2026, el 58,3% de quienes usan Zig quiere seguir usándolo, de acuerdo con el análisis comparativo citado más arriba.

¿Qué significa esto para tu startup?

Zig no es una apuesta de plataforma: es una apuesta de herramienta. Y como toda herramienta pre-1.0, se adopta por partes.

Prueba zig cc como cross-compiler en el CI. Si despliegas en edge, IoT o servidores con arquitecturas distintas, compilar binarios estáticos para varios targets sin mantener cadenas de herramientas propias es un ahorro inmediato. Empieza por un solo servicio y mide el tiempo de build antes de generalizarlo.
Copia el patrón de testeo de fallos. Aunque no escribas Zig, la idea de inyectar fallos en cada asignación es portable: envuelve tu malloc en C o usa un allocator de prueba y verifica que cada camino de error libera lo que debe. Es la clase de bug que solo aparece en producción y a las 3 de la mañana.
Pilota Zig en un módulo sin API pública. Dado el ritmo de cambios entre releases, elige una pieza interna —un parser, un códec, un cliente de red— y fija la versión del compilador en el CI. Si el módulo sobrevive a un par de actualizaciones, amplía el alcance.
No migres lo que necesita estabilidad contractual. Si tu producto depende de una API pública estable o de un pool de contratación amplio, C sigue siendo la respuesta aburrida y correcta.

Conclusión

C no se va a ninguna parte: el código de UNIX y la mayoría de las bibliotecas de sistema están en C, y sus páginas de manual lo documentan con prototipos de C. Pero para código nuevo, el argumento del autor es difícil de rebatir: Zig permite escribir el mismo tipo de código, cerca de la máquina y sin runtime, mientras el compilador y el modo debug atrapan errores que C deja pasar en silencio. La decisión sensata para un equipo no es elegir un bando, sino aprovechar que Zig compila C: empezar por el toolchain, seguir por los tests y dejar el cambio de lenguaje para el final.