Qué se sintió Zig, viniendo de Rust

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

La apuesta de Zig por ser un “C moderno” recibe reacciones mixtas de desarrolladores que vienen de Rust, y que comparan su gestión explícita de memoria, su diseño centrado en allocators y sus potentes funciones en tiempo de compilación con las mayores garantías de seguridad y la ergonomía funcional de Rust. Muchos ven Zig como atractivo para dominios de bajo nivel y críticos en rendimiento donde el control sobre la asignación y el diseño de datos importa, pero dudan de si eso compensa renunciar al borrow checker, al sistema de tipos más rico y a las herramientas maduras de Rust. El hilo también toca una incomodidad creciente con la escritura técnica editada por IA y una sensación más amplia de que los LLM están amortiguando el entusiasmo personal por aprender nuevos lenguajes de programación, incluso cuando el diseño de lenguajes y los conceptos siguen siendo cruciales para usar estas herramientas con eficacia.

Zig vs. Rust: Conclusiones generales

  • Muchos ven Zig como moderno, rápido y “similar a C pero más agradable”, con una fuerte interoperabilidad con C/C++ y compilación cruzada, pero claramente más joven y menos pulido que Rust.
  • Rust se presenta como un “lenguaje imperativo con fuerte influencia funcional”, bien adaptado a un nicho de “C++ reimaginado”, con herramientas e integración con IDE mucho más maduras.
  • Varios comentaristas enfatizan que Zig es intencionadamente de más bajo nivel y más explícito que Rust, sin asignación ni flujo de control ocultos; otros argumentan que Rust puede ofrecer un control igual de granular, solo que con más seguridad.

Estilo funcional vs. estilo imperativo

  • Las idiomáticas funcionales de Rust (iteradores, map/filter/flat_map, enums, pattern matching, tipos de error monádicos) son elogiadas por algunos como elegantes y expresivas, especialmente para el diseño de APIs.
  • Otros encuentran las largas cadenas de iteradores ilegibles y “desquiciadas” en comparación con bucles simples, y dicen que los entusiastas de Rust exageran los beneficios de legibilidad.
  • En Zig, un estilo funcional es posible, pero a menudo parece poco práctico porque hay que gestionar explícitamente los allocators; las transformaciones puras pueden volverse costosas en memoria o en seguimiento administrativo.
  • El debate sobre “monads” surge sobre todo en torno al uso extendido de flat_map y combinadores; algunos creen que esto es una elección de estilo, no una restricción dura del lenguaje.

Allocators, arenas y gestión de memoria

  • Gran subhilo sobre la “obsesión por los allocators” en Zig, Odin, Jai, etc.:
    • A favor: las arenas y los allocators personalizados son cruciales en juegos, kernels, bases de datos y cargas de trabajo en tiempo real o por petición/por frame; las políticas de asignación explícitas codifican decisiones importantes de rendimiento.
    • Escépticos: la mayoría del software del mundo real no necesita un diseño centrado en allocators; las APIs genéricas sobre el allocator pueden ser excesivas; los allocators de propósito general modernos (o mejores implementaciones de malloc) suelen ser suficientes.
  • Varios señalan que las arenas pueden simplificar la gestión de vida útil (liberar en bloque) y reducir el seguimiento manual de punteros, pero pueden aumentar el uso de memoria y complicar estructuras como tablas hash.
  • La ausencia de un allocator global en Zig obliga a que las estrategias de asignación sean explícitas (a menudo mediante parámetros), lo que algunos ven como una ventaja y otros como ruido.

Funciones en tiempo de compilación: comptime de Zig vs. const de Rust

  • Rust busca que la evaluación en tiempo de compilación se comporte idénticamente al tiempo de ejecución (las mismas semánticas del objetivo), lo que restringe lo que se permite (por ejemplo, funciones limitadas de punto flotante y traits en const).
  • El comptime de Zig es más potente y general, pero puede producir resultados que difieren entre tiempo de compilación y tiempo de ejecución, especialmente en punto flotante y diferencias de plataforma.
  • Algunos valoran las garantías más estrictas de Rust para builds reproducibles; otros prefieren la flexibilidad de Zig y consideran que su comptime es más efectivo en la práctica hoy en día.

Herramientas y experiencia de desarrollo

  • Las herramientas de Rust (cargo, integración con IDE, ecosistema) suelen considerarse muy por delante.
  • Se elogian la herramienta de línea de comandos de Zig y la compilación cruzada, pero la falta de soporte robusto en IDE se señala como un punto de fricción temprano y memorable.
  • Algunos aprecian redescubrir un flujo de trabajo “primero CLI” y archivos grandes y autocontenidos en Zig.

Hype de lenguajes, LLMs y motivación

  • Varios comentaristas expresan menos entusiasmo por los nuevos lenguajes en la era de los LLM, sintiendo que el conocimiento detallado del lenguaje importa menos cuando la IA escribe gran parte del código.
  • Otros argumentan que los conceptos, las abstracciones y el diseño de sistemas son más importantes que nunca, porque hay que guiar y validar la salida de los LLM.
  • Hay un malestar notable por los percibidos “AI-isms” en la prosa del artículo; algunos sugieren que ahora los redactores necesitan evitar conscientemente esos tics para parecer auténticos.

Filosofía lingüística más amplia

  • Algunos sostienen que nunca puede haber un “verdadero sucesor de C” porque la falta de funciones de seguridad de C es intencional para su uso como “ensamblador de alto nivel”; cualquier barandilla cambia la categoría.
  • Hay desacuerdo sobre si los lenguajes de sistemas (C, Rust, Zig) deberían usarse para aplicaciones en absoluto; algunos dicen que solo para SO/código de bajo nivel, otros señalan aplicaciones críticas de rendimiento (BDs, servidores, juegos) como buenos casos de uso.
  • Zig se ve como atractivo para desarrolladores a los que todavía les gusta C y quieren una variante moderna y explícita; Rust atrae más a quienes quieren seguridad fuerte y abstracciones.