¿Por qué Zig cuando ya existen C++, D y Rust?

Artículo original ↗ Discusión en Hacker News ↗

La filosofía de diseño de Zig —renunciar al flujo de control oculto, a las asignaciones implícitas, a la sobrecarga de operadores y a destructores al estilo RAII— provoca comparaciones intensas con C++, D, Rust, Go e incluso Jai. Sus defensores sostienen que el manejo explícito de errores, el paso de allocators y una biblioteca estándar amigable con freestanding hacen que Zig encaje bien en sistemas de bajo nivel, trabajo embebido y como reemplazo moderno de C, incluso si sacrifica cierta ergonomía y abstracción. Los escépticos responden que esos mismos rasgos lo hacen menos atractivo para aplicaciones de más alto nivel o código científico, y expresan preocupaciones sobre la estabilidad del lenguaje, la madurez del ecosistema y la ausencia de funciones como traits, cargas de error más ricas y sobrecarga de operadores amigable con matemáticas.

Actualizaciones del artículo y alcance

  • La página de comparación original de Zig se actualizó para corregir puntos desfasados, en particular la falta de un gestor de paquetes.
  • Algunos comentaristas sienten que la página enumera funciones, pero no dice con claridad “usa Zig si haces X”, lo que dificulta decidir para dominios específicos como la computación científica.

Flujo de control oculto y definición de flujo de control

  • Un gran subhilo debate qué significa “flujo de control”: algunos lo restringen a las condicionales; otros incluyen cualquier cambio en el orden de ejecución (llamadas a funciones, excepciones, interrupciones, goto).
  • El “no hay flujo de control oculto” de Zig se interpreta como “no hay llamadas a funciones invisibles ni saltos basados en excepciones”: deberías ver toda la ramificación y la propagación de errores en el punto de llamada.
  • Los críticos argumentan que funciones como defer/try son, en sí mismas, palabras clave de flujo de control poco obvias y que el término “oculto” está sobrecargado.

Asignación de memoria y allocators

  • Pasar allocators explícitamente se defiende como inversión de control y como una forma de evitar problemas de “color de función”.
  • Algunos ven los parámetros extra como una sobrecarga leve; los allocators globales siguen siendo una opción.
  • Preocupación: las bibliotecas aún podrían crear sus propios allocators o llamar directamente al sistema operativo. Quienes los defienden dicen que eso sería poco idiomático en Zig.
  • Se mencionan diseños basados en capacidades en otros lenguajes; los participantes argumentan que esto es difícil o imposible de hacer cumplir en un lenguaje de sistemas “sin runtime” como Zig.

Manejo de errores y excepciones

  • try/las uniones de error de Zig obligan a manejar o propagar explícitamente en los puntos de llamada, en contraste con las excepciones ocultas en C++/Java y los panic en Go/Rust.
  • Algunos ven el manejo de errores inline como ruidoso; otros dicen que try de Zig es ligero y más claro que las excepciones comprobadas.
  • Debate sobre si panic/recover de Go cuenta como excepciones; algunos insisten en que son “excepciones de pobres”.

RAII, destructores y limpieza de recursos

  • La falta de RAII/destructores es un factor decisivo negativo para varios participantes, que ven las llamadas explícitas de limpieza como verbosas y propensas a errores.
  • Otros prefieren vidas útiles explícitas, defer y patrones de allocators, argumentando que hacen más claros los puntos de limpieza y fomentan diseños que no requieren destructores.
  • El modelo RAII de Rust se cita como un punto medio atractivo.

Sobrecarga de operadores, abstracciones y matemáticas/cadenas

  • La ausencia de sobrecarga de operadores se elogia por evitar “llamadas ocultas” y DSL demasiado ingeniosos.
  • Los opositores dicen que perjudica el código numérico y de álgebra lineal, y hace más torpes la concatenación de cadenas y los números personalizados; la sintaxis tipo +/~ de otros lenguajes se ve como más ergonómica.
  • La postura pro-Zig argumenta que las abstracciones deberían ser funciones explícitas; los críticos responden que “menos trampas” puede valorarse en exceso frente a la expresividad.

Casos de uso y público objetivo

  • Los partidarios destacan la simplicidad de Zig, la biblioteca estándar opcional y el diseño freestanding como ideales para kernels, embebidos, EFI y trabajo de sistemas de bajo nivel.
  • Algunos ven potencial para desarrollo de videojuegos y tooling (por ejemplo, emuladores de terminal, runtimes web); otros dudan de su adecuación para codebases de alto nivel, intensivas en matemáticas o de estilo empresarial.

Estabilidad, ecosistema y riesgo de adopción

  • Debate sobre los plazos de estabilidad del lenguaje y si conviene apostar por Zig antes de 1.0.
  • Un lado subraya que los primeros adoptantes asumen costes de migración, comparándolo con los cambios previos a 1.0 de Rust y con Python 2→3; el otro señala el uso real creciente (por ejemplo, tooling web, sistemas de trading) como evidencia de que Zig es más que un juguete.
  • Hay tensión entre querer interoperabilidad con C y garantías: reutilizar mucho C socava parte de la seguridad y la narrativa de Zig.

Comparaciones con D, Rust, Go, Jai, C, etc.

  • Usuarios de D informan buen rendimiento y múltiples estrategias de asignación, y ven poca razón para cambiar solo por la página.
  • Se elogia Rust por su seguridad, pero se critica su complejidad, problemas de tooling y la falta de API de allocators / SIMD portable; algunos usuarios de Rust sienten curiosidad por Zig.
  • Se señala la falta de try/catch en Go; sus panic rara vez se usan para flujo de control, pero sí ocultan asignaciones (por ejemplo, defer).
  • Jai se discute, pero se descarta por ahora por ser cerrado/no liberado y por carecer de soporte embebido de 32 bits.
  • Algunos sostienen que C o sucesores tipo C (C3, otros) siguen siendo más simples; otros replican que la simplicidad de C oculta una gran brecha entre “sé escribir C” y “sé escribir C seguro y correcto”.