Zig: Toda la funcionalidad de gestión de paquetes se trasladó del compilador al sistema de construcción

La ética de desarrollo de Zig y el papel de los LLMs

• Varios comentaristas ven Zig como prueba de que “el software como oficio” sigue vivo, valorando el diseño humano deliberado por encima de los lenguajes generados por LLMs.
• Los LLMs se consideran excelentes para pequeños DSLs o tareas localizadas, pero no para código central de lenguajes/compiladores destinado a durar décadas.
• Preocupaciones: el código escrito por LLMs es verboso, la intención no está clara y revisarlo para sistemas críticos es difícil.
• Otros informan de un uso intensivo y exitoso de LLMs en bases de código de negocio, especialmente con estilos explícitos, defensivos y de baja abstracción que facilitan la revisión del código generado por IA.

Sistema de construcción, WebAssembly y sandboxing

• Hay entusiasmo por el plan de mover el sistema de construcción de Zig a una VM de WebAssembly para aislar build.zig.
• A favor del sandboxing:
  • Limita lo que pueden hacer los scripts de construcción no confiables, especialmente cuando editores/LSP los ejecutan automáticamente.
  • Permite un broker de privilegios más granular y una auditoría más sencilla de qué dependencias necesitan capacidades adicionales.
• Escepticismo:
  • Si los scripts de construcción aún pueden lanzar procesos arbitrarios (p. ej., cmake), el sandboxing es en parte “teatro de seguridad”.
  • Algunos argumentan que el sandboxing de todo el entorno/contenedor (bwrap, devcontainers, servidores aislados) es más apropiado.
• Contraargumento: la seguridad no es de todo o nada; un sandbox parcial sigue elevando la barrera y mejora la reproducibilidad.

Gestión de paquetes y preocupaciones sobre construcciones poliglotas

• Algunos lamentan que cada lenguaje invente su propio sistema de paquetes/construcción; preferirían un buen sistema poliglota y multiplataforma.
• Buck y Bazel se citan como lo más cercano a ese ideal, pero se ven lastrados por sus orígenes.
• Debate sobre si un sistema de construcción también debería ser un frontend de compilador o simplemente orquestar múltiples toolchains independientes.

Gestión de paquetes en C/C++ y cultura de dependencias

• Opiniones divididas sobre la falta de un gestor de paquetes estándar para C++:
  • Pro: obliga a seleccionar dependencias con cuidado y a actualizarlas manualmente, evitando árboles “a lo cargo” con cientos de crates transitivos.
  • Con: lleva a que cada gran proyecto C++ reimplemente componentes básicos (JSON, async, etc.), a menudo de forma deficiente.
• Conan y vcpkg se mencionan como soluciones de facto, pero no universalmente aceptadas.

Errores de diseño, evolución y el cambio de paquetes en Zig

• La analogía de “líquido del radiador en el tanque de combustible” se usa para criticar lenguajes que luego deshacen decisiones de diseño tempranas (p. ej., mover la gestión de paquetes fuera del compilador).
• Los defensores dicen que el acoplamiento estrecho inicial es una forma pragmática de lanzar e iterar; desacoplar antes de la 1.0 se ve como una evolución responsable.
• Algunos temen que los lenguajes modernos ignoren lecciones históricas; otros subrayan que el diseño de lenguajes es inherentemente iterativo y extremadamente difícil.

Impacto para el usuario (p. ej., @cImport)

• Un comentarista relaciona los cambios de paquetes/construcción con la eliminación anterior de @cImport, viéndolo como una pérdida de UX, aunque otros aclaran que las motivaciones son separadas (desacoplamiento de LLVM/libclang frente a refactorización de la gestión de paquetes).