You update your system, reboot, and suddenly your desktop is a scrambled mess. Your windows aren’t where they should be, your keybindings are dead, and your workflow is shattered. Why? Because the window manager you trusted just decided your config file needs to be a software program.
This is the reality for many Hyprland users right now. The beloved Wayland compositor recently pushed its switch to Lua for configuration files. On paper, it sounds brilliant. Lua is fast, lightweight, and expressive. But in practice, it’s a glaring symptom of a disease infecting modern software development.
When your configuration file can run a loop, it can also loop infinitely into a brick wall.
You’ve probably noticed this trend everywhere. We saw it with Gradle’s Groovy abominations. We see it with Nix, where configuring a simple package manager requires learning a bespoke functional programming language. Now, we’re seeing it with Hyprland.
Developers love it. They see infinite possibilities. They get excited about dynamic logic, conditional rules, and programmatic layouts. But users are exhausted. One commenter on the Hyprland update summed it up perfectly: “I might be a good change but I left hyprland because, my configuration kept breaking. It’s a good window manager so I’ll change back once it gets stable.”
This isn’t just a technical debate about Lua versus a static format like JSON or TOML. This is a philosophical war between user empowerment and user protection. We are told that giving users a Turing-complete language for their configs is the ultimate freedom. It’s a lie.
Empowerment isn’t handing someone a loaded gun for a task that desperately needs a scalpel.
Every time you introduce a programming language into a config file, you introduce breaking changes. You introduce a steep learning curve. You force users to debug runtime errors just to change their wallpaper or adjust their gaps. The complexity overhead skyrockets, and the stability plummets.
If you configure any software—whether it’s a window manager, a CI/CD pipeline, or a build system—this decision directly affects your daily life. More power always means more maintenance. When you choose a Turing-complete config language, you aren’t betting on flexibility; you’re betting that you’ll have the time and energy to maintain a mini-codebase every time the upstream project updates.
We need to stop celebrating complexity disguised as capability. A configuration file should declare state, not execute logic. It should be easily parsed, easily diffed, and boring. If you want to write code, write an application. If you want to configure one, use a static format.
Software should get out of your way, not trap you in its source code. Keep your configs static, and let your code live where it belongs.
FAQ
Q: Isn't Lua lightweight and easy to learn compared to other languages?
A: Lua is lightweight, but a 'lightweight programming language' is still a programming language. It requires debugging, logic testing, and syntax maintenance that static formats like TOML or JSON simply don't.
Q: What does this mean for my daily software setup?
A: If your tools use Turing-complete configs, expect to spend more time maintaining your setup than actually using it. Every upstream update risks breaking your custom logic.
Q: Shouldn't power users have the right to write code in their configs?
A: Power users can write external scripts that read static configs and generate dynamic states. Forcing everyone into a programming language just to set basic preferences punishes the 99% for the 1%'s edge cases.