Hyprland 0.55 anunció el cambio a Lua para sus archivos de configuración
El paso de Hyprland en la versión 0.55 a una configuración basada en Lua ha reavivado preguntas más amplias sobre el uso de lenguajes de programación completos para configurar gestores de ventanas. Quienes lo apoyan celebran Lua por su velocidad, flexibilidad y programabilidad de primera clase, especialmente para comportamientos y disposiciones complejas; quienes lo critican señalan la inestabilidad, los frecuentes cambios incompatibles y la carga de mantenimiento a largo plazo de las configuraciones Turing completas. El hilo contrapone Hyprland con alternativas como i3, Sway, Niri, AwesomeWM y otras, destacando un recurrente “péndulo de la configuración” entre formatos declarativos simples y sistemas de configuración cada vez más potentes y parecidos al código.
Contexto del lanzamiento y herramientas
- Varios comentaristas señalan que el cambio a Lua es “vieja noticia” porque Hyprland 0.56 ya está disponible, pero muchos siguen viendo el paso a Lua como la parte interesante de 0.55.
- Los usuarios mencionan varios convertidores del antiguo lenguaje de configuración de Hyprland a Lua (herramientas web, un plugin de Neovim) y dicen que los LLM también pueden traducir configuraciones con eficacia.
- Algunos solo se dieron cuenta del cambio después de haber pasado ya a 0.56 y planean retrasar la migración hasta que las herramientas y los ejemplos maduren.
Estabilidad, roturas e impacto en el ecosistema
- Varios usuarios informan haber dejado Hyprland (temporal o permanentemente) debido a cambios frecuentes que rompen la configuración, especialmente en la sintaxis y en la reorganización de opciones.
- Otros dicen que Hyprland funciona bien si construyes una configuración simple y que entiendas por ti mismo, en lugar de copiar grandes configuraciones de terceros; describen que las correcciones son fáciles, pero reconocen que es software 0.x.
- Un usuario de NixOS critica el ecosistema de Hyprland por bifurcar gran parte de la pila de Sway con paquetes que avanzan rápido y rompieron la compilación cruzada, llamándolo energía de “no nos importa si rompemos tus cosas”.
- Varias personas volvieron a i3, Sway o Niri por una mayor estabilidad y simplicidad percibidas; el autor de Niri es descrito como más “maduro”.
Usar un lenguaje de programación para la configuración: escepticismo
- Muchos expresan fatiga con configuraciones Turing completas (Groovy de Gradle, Nix, Lua, etc.), citando complejidad, razonamiento más difícil y actualizaciones frágiles.
- Algunos sostienen que la configuración debería ser declarativa y “tonta” (INI/TOML/KDL/DSL al estilo OpenBSD), con la lógica real en plugins o programas externos mediante IPC.
- Las preocupaciones incluyen ciclos de “péndulo/reloj” de la configuración: simple → capas de sobrescritura → lenguaje completo → reinicio eventual.
- Quejas específicas sobre Lua incluyen arrays indexados desde 1, tablas para todo y falta de tipos estáticos; algunos desearían un lenguaje moderno, tipado y embebible, parecido a Lua.
Usar un lenguaje de programación para la configuración: apoyo
- Quienes lo apoyan argumentan que los WM, editores y terminales complejos se benefician de configuraciones programables para callbacks, disposiciones, comportamiento específico por dispositivo y para evitar frágiles trucos de shell/plantillas.
- Señalan que, sin un lenguaje, los usuarios terminan reinventando DSL ad hoc o generadores sobre YAML/JSON de todos modos.
- Lua es elogiado por ser pequeño, embebible, diseñado originalmente para configuración y bien dotado de herramientas (por ejemplo, LSP para introspección y autocompletado).
- Para los gestores de ventanas en particular, muchos ven Lua embebido como más limpio y rápido que invocar procesos externos vía IPC en cada evento.
Enfoques alternativos para la configuración
- Algunos prefieren modelos híbridos: configuraciones declarativas simples más capas opcionales de scripting, o demonios complementarios que amplían una configuración mínima del WM.
- Otros destacan alternativas como CUE, Dhall, Jsonnet, KDL y scfg como lenguajes de configuración no Turing completos pero expresivos, especialmente valorados en contextos de infraestructura.