Hyprland switched its configs to Lua. The thread argued about dwm instead.

Lua replaces hyprlang, and nothing breaks today

Hyprland is a tiling Wayland compositor with a devoted, fast-moving Linux desktop following, and its 0.55 release is the one where the project finally replaced its home-grown config language, hyprlang, with real Lua — variables, loops, functions, the works. Old-style configs keep working for "a few releases" while the wiki catches up with Lua-first docs, and a community-built converter plus at least one neovim plugin already translate existing setups line by line; commenters said LLMs handle the conversion without much fuss too.

The release also shipped a Layout API that lets users write custom tiling layouts that behave exactly like Hyprland's built-in ones — global, per-workspace, or per-monitor — along with per-output ICC color-profile support, FP16 rendering for better color accuracy, a new window glow effect, and native trackpad gestures. Four old config options got removed or relocated in the process, the kind of breaking change 0.x software users are expected to absorb.

By the time this thread got going, Hyprland had already shipped 0.56, and a chunk of the early replies were just pointing that out. One longtime user put the correction in context: switching to Lua "doesn't matter that it happened a few weeks ago" — the changelog timing was noise; the argument that followed was about something the release notes never mention at all.

Why turn a window manager's config into a real programming language

That argument started with a flat complaint about the whole category of software that does this, config-as-code, invoking a "Gradle Groovy abomination" as the cautionary tale. The reply that got the most traction turned the complaint back on itself:

"So you don't like using programming languages as config languages, so you: 1. Use a declarative-style format for config, which is fine, I guess; 2. ... and when that inevitably fails, you... use a programming language? Some people... may prefer to skip the first step and go straight for the second option." — creator of masteringemacs.org and inspiredpython.com

A dozen replies branched off from there — CUE schemas, TOML purists, the OpenBSD school of tiny DSLs — but the practical case for Lua specifically came down to introspection: a Lua config gets you a real language server, autocomplete, and documented fields instead of guessing at an undocumented DSL.

The packaging bill nobody put in the release notes

The sharpest pushback wasn't about syntax at all. It came from someone who has spent the last year keeping Hyprland buildable outside its own ecosystem:

"i put in a sizable effort getting the whole sway stack to cross compile correctly in nixpkgs/NixOS, keeping that stable for a year so that people could build on it, and then suddenly hyprland forked every package in the stack with a fresh set of 'works on my machine' nix expressions... it gives 'rewrite it in rust' vibes in the way they rush in to re-do everything without understanding why things were the way they were." — a Nix packager who spent a year keeping the sway/Hyprland stack cross-compiling in nixpkgs

Mainline nixpkgs support for Hyprland's own packages, by his account, has been broken for a year; he eventually just nulled the packages out of his personal config. A config-language rewrite doesn't stay contained to the config parser — every downstream packager and status-bar plugin author inherits the churn.

dwm's answer: don't configure it, recompile it

One reply skipped the Lua-vs-DSL argument entirely and reached for the opposite philosophy:

"I think dwm has the best approach to configuration: change the program and recompile. This works for dwm because it compiles in two seconds and has minimal dependencies. I don't know about hyprland." — author of *Practical Julia* and *Einstein's Tutor*

Nobody seriously proposed that Hyprland — a C++ compositor with a much larger dependency graph than suckless's C tools — adopt dwm's edit-and-recompile model. But the contrast is the point: dwm treats "customize the source" as simpler than any config language, Turing-complete or not.

One reply zoomed out to name the pattern the whole thread had been circling:

"Simple config -> (Need to do more complicated things) -> Add override levels -> ... Add a Turing complete language -> (Things get ridiculous, lots of spaghetti code outside of version control. Time for a reset) -> goto 'Simple config'... think of it as a spiral. The next 'Simple config' is a slightly better version of the first." — a distributed-systems engineer with 45,000-plus karma since 2009

Hyprland just picked its moment to swing toward the language end of that spiral. Whether it swings back is the part no thread can answer yet.