Hyprland 0.55 announced the switch to Lua for its config files
Hyprland’s move in version 0.55 to Lua-based configuration has reignited broader questions about using full programming languages to configure window managers. Supporters welcome Lua for speed, flexibility, and first-class programmability—especially for complex behaviors and layouts—while critics cite instability, frequent breaking changes, and the long-term maintenance burden of Turing-complete configs. The thread contrasts Hyprland with alternatives like i3, Sway, Niri, AwesomeWM, and others, highlighting a recurring “config pendulum” between simple declarative formats and ever more powerful, code-like configuration systems.
Release context and tooling
- Several commenters note the Lua switch is “old news” because Hyprland 0.56 is already out, but many still see the Lua move as the interesting part of 0.55.
- Users mention multiple converters from the old Hyprland config language to Lua (web tools, a Neovim plugin), and say LLMs can also translate configs effectively.
- Some users only noticed the change after already being on 0.56 and plan to delay migration until tooling and examples mature.
Stability, breakage, and ecosystem impact
- A number of users report leaving Hyprland (temporarily or permanently) due to frequent breaking config changes, especially syntax and option reshuffles.
- Others say Hyprland works fine if you build a simple, self-understood config instead of copying large third‑party setups; they describe fixes as easy but acknowledge it’s 0.x software.
- One NixOS user criticizes Hyprland’s ecosystem for forking much of the Sway stack with fast‑moving packages that broke cross‑compilation, calling it “we don’t care if we break your stuff” energy.
- Several people reverted to i3, Sway, or Niri for perceived greater stability and simplicity; Niri’s author is described as more “mature”.
Using a programming language for config: skepticism
- Many express fatigue with Turing‑complete configs (Gradle Groovy, Nix, Lua, etc.), citing complexity, harder reasoning, and fragile upgrades.
- Some argue config should be declarative and “dumb” (INI/TOML/KDL/OpenBSD‑style DSLs), with real logic in plugins or external programs via IPC.
- Concerns include “config pendulum/clock” cycles: simple → layered overrides → full language → eventual reset.
- Specific complaints about Lua include 1‑indexed arrays, tables‑for‑everything, and lack of static types; some wish for a modern, typed Lua‑like embeddable language.
Using a programming language for config: support
- Supporters argue complex WMs, editors, and terminals benefit from programmable configs for callbacks, layouts, device‑specific behavior, and avoiding fragile shell/templating hacks.
- They note that without a language, users reinvent ad‑hoc DSLs or generators over YAML/JSON anyway.
- Lua is praised as small, embeddable, designed originally for configuration, and well‑tooled (e.g., LSP for introspection and completion).
- For window managers specifically, many see embedded Lua as cleaner and faster than shelling out via IPC on every event.
Alternative configuration approaches
- Some prefer hybrid models: simple declarative configs plus optional scripting layers, or companion daemons that extend a minimal WM config.
- Others highlight alternatives like CUE, Dhall, Jsonnet, KDL, and scfg as non‑Turing‑complete but expressive config languages, especially valued in infrastructure contexts.