Hyprland 0.55 anunciou a mudança para Lua nos seus ficheiros de configuração
A mudança do Hyprland na versão 0.55 para configuração baseada em Lua reacendeu questões mais amplas sobre o uso de linguagens de programação completas para configurar window managers. Os defensores acolhem o Lua pela rapidez, flexibilidade e programabilidade de primeira classe — especialmente para comportamentos e layouts complexos — enquanto os críticos apontam a instabilidade, as quebras frequentes e o custo de manutenção a longo prazo de configs Turing-complete. O debate contrapõe o Hyprland a alternativas como i3, Sway, Niri, AwesomeWM e outras, destacando um recorrente “pêndulo da configuração” entre formatos declarativos simples e sistemas de configuração cada vez mais poderosos, semelhantes a código.
Contexto do lançamento e ferramentas
- Vários comentadores observam que a mudança para Lua é “notícia velha” porque o Hyprland 0.56 já foi lançado, mas muitos ainda veem a passagem para Lua como a parte interessante da 0.55.
- Utilizadores mencionam vários conversores da antiga linguagem de configuração do Hyprland para Lua (ferramentas web, um plugin para Neovim) e dizem que os LLMs também conseguem traduzir configs de forma eficaz.
- Alguns só repararam na alteração depois de já estarem na 0.56 e planeiam adiar a migração até as ferramentas e exemplos amadurecerem.
Estabilidade, quebras e impacto no ecossistema
- Vários utilizadores relatam ter deixado o Hyprland (temporária ou permanentemente) devido a mudanças frequentes que quebram a configuração, especialmente sintaxe e reorganização de opções.
- Outros dizem que o Hyprland funciona bem se se construir uma configuração simples, compreendida pelo próprio, em vez de copiar grandes setups de terceiros; descrevem correções como fáceis, mas reconhecem que é software 0.x.
- Um utilizador de NixOS critica o ecossistema do Hyprland por fazer fork de grande parte da stack do Sway com pacotes de evolução rápida que quebraram a cross-compilação, chamando-lhe energia de “não nos importamos se lhe estragarmos as coisas”.
- Várias pessoas voltaram ao i3, Sway ou Niri por considerarem que oferecem maior estabilidade e simplicidade; o autor do Niri é descrito como mais “maduro”.
Usar uma linguagem de programação para configuração: ceticismo
- Muitos demonstram cansaço com configs Turing-complete (Gradle Groovy, Nix, Lua, etc.), citando complexidade, raciocínio mais difícil e upgrades frágeis.
- Alguns defendem que a config deve ser declarativa e “burra” (INI/TOML/KDL/DSLs ao estilo OpenBSD), com a lógica real em plugins ou programas externos via IPC.
- As preocupações incluem ciclos do tipo “pêndulo/relógio da config”: simples → overrides em camadas → linguagem completa → reinício eventual.
- Queixas específicas sobre Lua incluem arrays indexados a partir de 1, tabelas para tudo e ausência de tipos estáticos; alguns gostariam de uma linguagem moderna, tipada e embebível, semelhante a Lua.
Usar uma linguagem de programação para configuração: apoio
- Os defensores argumentam que WMs, editores e terminais complexos beneficiam de configs programáveis para callbacks, layouts, comportamento específico por dispositivo e para evitar hacks frágeis de shell/templating.
- Observam que, sem uma linguagem, os utilizadores acabam por reinventar DSLs ad hoc ou geradores por cima de YAML/JSON na mesma.
- O Lua é elogiado por ser pequeno, embebível, originalmente concebido para configuração e bem equipado com ferramentas (por exemplo, LSP para introspeção e autocompletar).
- No caso específico dos window managers, muitos veem o Lua embebido como mais limpo e mais rápido do que recorrer ao shell via IPC em cada evento.
Abordagens alternativas de configuração
- Alguns preferem modelos híbridos: configs declarativas simples mais camadas opcionais de scripting, ou daemons companheiros que estendem uma config mínima do WM.
- Outros destacam alternativas como CUE, Dhall, Jsonnet, KDL e scfg como linguagens de configuração não Turing-complete, mas expressivas, especialmente valorizadas em contextos de infraestrutura.