Hablemos de ZIG

Lo estamos consiguiendo, chicos.

¿A qué te refieres, Hexa?

Prometí que daríamos voz y voto a lenguajes de bajo nivel, y aquí vamos por otro de los lenguajes que no superaron encuestas pasadas.

Esto se debe a mi pericia e ideas con el sistema de votaciones.

Sí, por supuesto, Chip. Por lo pronto, hemos visto a muchos lenguajes que querían quitarle el puesto al lenguaje C.

Totalmente, aunque en esa lista hay muchos más. Déjame enumerar.

Oh no, aquí vamos.

C++, Objective-C, D, Go, Rust, Sig, bala, uve y here.

Exacto, aunque seguro que hay muchos más. El lenguaje C, tal y como dijimos en un capítulo anterior, es la raíz de muchos de los lenguajes, y muchos de los lenguajes que llegaron después solo intentan derrocar al rey.

Pues C está muy cerca de conseguirlo.

No estoy muy seguro de eso, y además aún está en una versión lejana a la 1.0.

Eso no importa, porque como verás, el tablero de juego ya ha sido dispuesto.

¿Te gustaría decidir los temas que trataremos en el canal?

Pues lo tienes muy fácil.

Entra en nuestra página web, accede con tu cuenta de Google y vota por tu favorito.

Puedes votar una vez al día para que gane el tuyo.

Eso no es trampa.

Serán tomadas en cuenta todas vuestras sugerencias en comentarios, en publicaciones y vídeos además.

Y ya que estamos, ¿por qué no darle me gusta, suscribirse y hacerse miembro?

Eso ya saben cómo hacerlo, Violeta. Estamos hablando de votos.

Totalmente. ¡Hagamos que ganen esos lenguajes de bajo nivel, chicos!

Sigamos con el vídeo.

Lo que C no pudo hacer. Uno de los problemas del lenguaje C es el preprocesador.

¿Uno solo?

Yo no lo veo un problema. Es verdad que son macros y hay que tener cuidado con ellas, pero si lo haces bien, tienen un gran potencial y son muy sencillas.

Pero no lo controla el compilador. De hecho, es fácil romper algo y no saber dónde está el fallo.

Discutible.

Andrew Kelly, el creador de Zig, es uno de los nuestros y un programador de aplicaciones de bajo nivel. Aplicaciones que tocan elementos de bajo nivel o hardware directamente.

¿Y por qué no mejorar C en lugar de escribir un lenguaje nuevo de programación?

En verdad, esa fue la idea inicial. Hizo un fork de C y comenzó a agregar sus modificaciones. Pero pronto fueron tantas que sabía que el comité a cargo del estándar de C no las aceptaría.

Normal. C está bien tal y como está, ¿por qué cambiarlo?

Para modernizarlo y hacer del compilador un aliado en tener un código óptimo.

Vayamos al punto interesante. Una vez que Andrew supo que no aceptarían los cambios, lo comenzó a usar como su propio lenguaje, ¿no?

Totalmente. En este momento supo que debía crear su propio lenguaje.

Pues vamos a la duda que llega en cada uno de los lenguajes de los que hablamos: ¿por qué C? ¿Por qué lo llamó así?

Pues como buen programador hizo un script para elegir el nombre.

Me agrada que hayas usado Python para generar esos nombres, pero tengo algunas dudas. ¿Por qué debía comenzar por Z? ¿Por qué debía tener una vocal o I como segunda letra? Y sobre todo, ¿por qué eligió Zig si el script genera posibles nombres de 4 letras?

Nadie es perfecto. Después de varias generaciones salió algo similar a Zig y le gustó el nombre.

Además, hace un buen juego de palabras. Por un lado con zigzag—

Eso no lo veo positivo. Algo que hace zigzag es que no es claro ni directo.

Pero abarca más.

Y por otro lado, En inglés, Zig tiene una pronunciación similar a sí.

Da a entender bien por qué es uno de los lenguajes más populares.

Vale, centrándonos en esto, ¿qué lo hace diferente? ¿Cuándo surgió Zig?

La primera versión es de 2016.

Ya existía Rust, ¿por qué no usar Rust?

Si recuerdas nuestro capítulo sobre Rust, antes de llegar a su versión 1.0, Rust era un poco inestable en cuanto a características.

Sí, pero el principal problema es la gestión de memoria de Rust. Te da seguridad, pero tienes que cambiar la forma de diseñar tus programas para encajar en esa forma.

No es un gran problema, pero es verdad que ese pequeño cambio hace más complicado el lenguaje. Y Zig, al ser como C pero con facilidades, se percibe incluso mucho más fácil sin restar potencia.

¡Y debe serlo! ¿Habéis visto las compañías que usan a día de hoy Zig?

Totalmente. Ahí están Revolut o Badoo entre los más conocidos.

Entonces debe existir algo que lo haga diferente y más llamativo para estas empresas.

Creo que simplemente haber estado en el lugar y momento adecuados.

¿A qué te refieres?

Noticias como esta comenzaron a llegar. Rust abrió camino y en 2020 lanzó su versión estable 1.0. Su marketing buscaba reescribirlo todo y hacerlo más seguro.

Pero entonces comenzó a popularizarse Zig con un mensaje más claro y conciliador para quienes programan en C: pragmático, interoperable y sencillo.

Las promesas de su página web: simple, sin flujos de control ocultos, sin reservas de memoria ocultas Sin preprocesador y sin macros.

Yo aún sigo pensando que las macros no son el problema.

Hay mejores formas de hacer esas macros, y Zig topó con la ejecución en tiempo de compilación o compile time.

Otra vez vamos a eso de que hacer cosas en tiempo de compilación es mejor que en tiempo de ejecución.

Totalmente, te da mayor seguridad y comprobaciones para evitar errores en el código.

Aunque no podemos obviar las pruebas en el código.

Esto también lo mejora sustancialmente, nos permite escribir mejores tests.

Un momento. ¿Por qué no hay versión 1.0? Estamos asumiendo que Zig es un lenguaje prometedor, incluso maduro.

No hemos dicho eso, pero en su versión actual 0.15 podríamos decir que sí.

Como diría Pro: ¡Exacto! No ha llegado a su versión 1.0. Si es tan estable, ¿por qué no hay versión 1.0?

Porque Andrew es un poco idealista y ha puesto muchas características que le gustaría tener para la versión 1.0.

Es verdad que en una entrevista en 2020 dijo que en un par de años seguro que podríamos ver una versión 1.0, y hay una entrada en Reddit de principio de 2025 donde se estima que aún queda lejos y sin fecha estimada esa versión 1.0.

Es curioso que no habiendo llegado aún a su versión 1.0 tenga detrás empresas patrocinando y usando el lenguaje. ¿Qué características son las que deberían entrar que aún no están? ¿Tan?

Pues a día de hoy hay aún 78 issues abiertos en GitHub.

Hay que actualizarse, pro. Zig ya no está en GitHub. Es decir, a finales de noviembre de 2025 decidieron migrar todo a CodeBear.

Pero tienen muchos sponsors en GitHub.

De momento han dejado los repositorios en GitHub en modo solo lectura y con el tiempo darán solución a todo.

O terminarán volviendo algunos meses después como los que dijeron que se iban de X.

No creo que sea lo mismo, Chip. El movimiento se está haciendo porque GitHub no funciona bien. En la carta publicada por Andrew lo dice.

Pero no nos desviemos. El plan para la versión 1.0 aún no se ha fijado.

No es nada positivo, siento decírtelo, Hexa.

Pero hay que reconocer que aún no teniendo un plan para la versión 1.0, el lenguaje es querido.

Totalmente. Zig se usa, y mucho. No tienen roturas entre versiones e incluso mantienen sus promesas siendo un lenguaje al que migrar desde C bastante consistente.

¿Cómo deficiente es C? Es raro que aún no hayas sacado el tema.

Lo he dicho desde un principio, C es igual de eficiente que C. De hecho, el compilador de C puede compilar código en C.

¿No es un transpilador a C como Nim?

No, es un compilador basado en LLVM.

LLVM es una tecnología interesante aunque algo pesada.

Es una tecnología óptima y muy usada en compiladores como Clang, Swift, Rust y muchos otros.

Según la entrevista a Andrew, esto es en verdad algo a mejorar y están trabajando en ello.

El compilador de Zig, de hecho, tiene diferentes hitos. El primero en el que existe soporte de LLVM es el Stage 1. A finales de 2022 se lanzó Stage 2, que está escrito en Zig y es un compilador propio.

Se puede compilar a sí mismo, como todo buen compilador de bajo nivel que se precie.

Pero aún no está acabado. Convive con partes de LLVM que aún son necesarias, como la optimización avanzada, el soporte multiplataforma y parte del ecosistema para depuración y enlazado de bibliotecas.

Pero tenemos ya disponible WebAssembly y se está avanzando a muy buen ritmo.

Pero eso ya lo tiene C desde hace años.

Vale, chicos, quedó claro. Zig avanza a pasos agigantados y tiene mucho recorrido aún por delante.

Sí, por ese motivo deberíamos seguir usando C.

Zig es maduro y lo puedes ver en muchos desarrollos hechos con Zig. Por ejemplo, uno de los mejores sistemas de ejecución para JavaScript Boom está hecho en CIG.

Parece que también hay una base de datos de transacciones financieras hecha en CIG.

Y no hay que perderse la sección de Awesome CIG en GitHub sobre sistemas operativos y núcleos.

Ya tiene que ser fácil para que tanta gente quiera hacerse su propio sistema operativo.

Es lo mejor para practicar.

Hacerse un sistema operativo. Yo prefiero hacer un pequeño juego.

También los hay.

Conclusiones.

Aún no hemos hecho la prueba de código.

Doy por hecho que será un código de bajo nivel, como el que aparece en la página principal. De CIG.

Eso es un simple test sobre los números enteros.

¿Es que ya nadie piensa en el típico hola mundo?

Bueno, resumamos.

Yo me quedo con que CIG es un lenguaje simple que apareció discretamente a partir de ciertas modificaciones en el lenguaje C y que ha mantenido tal nivel de interoperabilidad que se está convirtiendo en el verdadero sucesor de C. Me niego a pensar eso.

Tiene muchas y muy buenas ideas implementadas. El trabajo continúa gracias a SIG Software Foundation. Por lo que ya sabéis, si queréis apoyar a Andrew en su cruzada de obtener cada vez un mejor lenguaje de programación, haced una donación.

Y ahora os toca a vosotros. ¿Sabíais de la existencia de SIG?

¿Os apetecería hacer un proyecto con él? ¿Tenéis alguna idea? ¿No? ¿Queréis ideas?

¿Sabíais que el curso en nuestra página web tendrá SIG dado por Hexa?

¡Totalmente! Quiero decir, déjanos tu comentario.

Habéis vuelto a comentar lo del curso, pero no vamos avanzando, ¿pro?

Está más cerca de lo que parece. De momento veo que ya hay personas esperándolo, así que lo lanzaremos en breve.

¿Antes de que acabe el año?

Puede que no tan pronto, pero llegará. Continuará.