Cuatro meses de Zig

Gestión de errores y diagnósticos

• Se destacan el operador ? de Rust y la composición de errores basada en From como potentes pero “quisquillosos”, y a menudo requieren tipos de error personalizados o crates auxiliares.
• Los conjuntos de errores de Zig se consideran más simples y más “integrados”, pero no transportan de forma natural un contexto rico ni anidamiento; conservar diagnósticos detallados suele requerir más trabajo manual.
• Algunos sostienen que el modelo de Zig fomenta desechar información útil de depuración; otros aprecian la simplicidad y ven el contexto adicional como una responsabilidad explícita.

Allocators, arenas y control sobre la memoria

• Hay un fuerte apoyo al modelo explícito de allocators de Zig en bibliotecas y código de sistemas: quien llama mantiene el control, el código puede ejecutarse en entornos restringidos o personalizados, y se evitan allocators globales.
• Se elogian las arenas por agrupar asignaciones por tiempo de vida (por ejemplo, por solicitud HTTP), reducir la fragmentación, evitar liberaciones por objeto y acotar el uso de memoria.
• Los críticos señalan que las arenas pueden filtrar memoria si se calculan mal los tiempos de vida, no siempre son más rápidas que mallocs ajustados, y complican las estructuras que crecen; consideran que el patrón de Zig de “pasar el allocator a todas partes” es verboso y frágil comparado con RAII/GC.
• Debate sobre almacenar allocators en estructuras de datos (estilo Odin) frente a pasarlos en cada llamada: compensaciones entre sobrecarga de memoria en tiempo de ejecución y ruido en el punto de llamada, además del riesgo de allocators no coincidentes.

Async e interfaz de IO

• Los intentos anteriores de “async sin color” se critican por ser implícitos; el diseño actual de Zig usa una interfaz de IO explícita con despacho dinámico, y permite elegir entre backends bloqueantes y asíncronos.
• Algunos ven esto todavía como “magia oculta” porque el comportamiento puede cambiar detrás de la misma API; otros insisten en que es solo indirección a nivel de biblioteca, no magia del compilador, y que está totalmente documentado.

TigerStyle y pensamiento orientado al rendimiento

• TigerStyle (diseñar pensando primero en el hardware) se considera por algunos más bien sentido común y difícil de aplicar perfectamente sin perfilar.
• Otros sostienen que importa más para sistemas grandes y arquitecturas que para corregir cuellos de botella locales; aun así, varios señalan que las restricciones muy especializadas de TigerBeetle limitan su aplicabilidad general.

Biblioteca estándar, APIs de plataforma y seguridad

• La reimplementación por parte de Zig de libc, crypto, compression y el uso de APIs NT de Windows de bajo nivel en lugar de la superficie oficial Win32 atrae críticas por ser arriesgada e incompatible con las expectativas de los antivirus.
• Quienes la defienden dicen que las APIs NT son más limpias y más parecidas a Unix, lo que ayuda al código multiplataforma; los escépticos sienten que estas decisiones minan la confianza en Zig como un lenguaje de producción “serio”.

Estabilidad, ergonomía y herramientas

• Los cambios de ruptura frecuentes (por ejemplo, la evolución de la interfaz de IO) son un gran punto de dolor, especialmente para proyectos grandes.
• La falta de soporte sólido de IDE y de autocompletado para código comptime se reporta como un factor decisivo en contra para algunos.
• En conjunto, Zig se considera excelente para dominios de bajo nivel y alto control, pero muchos participantes prefieren Rust/Go para aplicaciones generales y trabajo con muchas herramientas.