Hyprland 0.55 announced the switch to Lua for its config files • Hacker News Board

Re: Hyprland 0.55 announced the switch to Lua for its config files

#41

Post by weinzierl » Mon, Jul 20, 2026, 7:19 PM UTC

Tables.

Not from TOML, just from my config language. TOML has other applications that require its complexity.

I'd still keep simple INI style sections in my config lang, but they wouldn't have deeper meaning apart from grouping.

Re: Hyprland 0.55 announced the switch to Lua for its config files

#42

Post by mort96 » Mon, Jul 20, 2026, 7:21 PM UTC

All these window managers have a Turing complete configuration language, because you need to do things in response to events (keyboard hotkeys etc). It's just that for most of them, the "Turing completeness" happens through passing around strings with shell snippets. Might as well be a Lua callback function.

Re: Hyprland 0.55 announced the switch to Lua for its config files

#43

Post by crest » Mon, Jul 20, 2026, 7:22 PM UTC

A window manager / compositor is one of the few things where I can see this making a lot of sense. The alternative of using an IPC socket for everything would be more complex and require users to reinvent the wheel all the time. Also it makes low latency synchronous reactions to events really hard to implement well.

Re: Hyprland 0.55 announced the switch to Lua for its config files

#44

Post by kibwen » Mon, Jul 20, 2026, 7:24 PM UTC

Seconded. Your configuration should be a simple declarative language with no Turing-complete escape hatches. Turing-complete configuration languages are the devil. That goes for build systems too: if you absolutely need Turing-completeness in your build system (my condolences for the hellscape you inhabit), use a separate task runner that does its arbitrary nonsense before dispatching to an underlying build system with declarative configuration.

Re: Hyprland 0.55 announced the switch to Lua for its config files

#45

Post by feelamee » Mon, Jul 20, 2026, 7:25 PM UTC

there is a converter: https://eiontusk.github.io/hyprlang2lua/

Re: Hyprland 0.55 announced the switch to Lua for its config files

#46

Post by nimih » Mon, Jul 20, 2026, 7:28 PM UTC

Speaking personally, there are essentially two distinct reasons I like having programmable config languages:

- For personal application config (window manager, shell, text editor, etc), I find I often want to have site-specific configuration, but I also want identical configuration files at every workstation. My laptop probably needs slightly different keybindings than my desktop, my $PATH and text editor needs to be configured a bit differently for work than for personal use, etc. When the configuration is done with a real programming language, this is always straightforward, when it's done via a json/yml/toml file, it's usually a huge pain in the ass.

- You want templating for your configuration, to improve readability, reduce typos and configuration drift, &c, but if you give programmers an inch with any sort of templating system, they will eventually take a mile and figure out how to smuggle Turing-completeness (or, at least, for-loops and variable binding and probably closures) into their configs. If you have a real programming language, this is fine, because the programming language was designed to make loops and conditionals and function calls readable, and probably has decent tooling to boot, but if they're doing it with, say, Mustache-templated YAML, you will have an unreadable mess that is extremely unpleasant to work with.

Re: Hyprland 0.55 announced the switch to Lua for its config files

#47

Post by corysama » Mon, Jul 20, 2026, 7:31 PM UTC

Lua was specifically designed to be a configuration language https://www.lua.org/history.html

Lots of people start out with a non-programmable config format. But, as their situation becomes more complicated, they end up shoehorning in programmable-ish features until they realize they are running straight into https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule and decide to do it properly.

Re: Hyprland 0.55 announced the switch to Lua for its config files

#48

Post by kibwen » Mon, Jul 20, 2026, 7:31 PM UTC

All scalar types other than strings (especially nonsense like datetimes). I'm already ingesting the configuration file as a string and parsing it into a language with actual types, e.g. Rust, and the act of parsing it into my defined configuration type will itself identify any problems with the config; having half-assed types like "int" in the config file format itself is not only useless, it's counterproductive because it requires people to ask questions like "okay, but what actually is the maximum range of integer values allowed to be contained in this type?". Just enforce UTF-8 encoded string values and let me take care of data validation.

Re: Hyprland 0.55 announced the switch to Lua for its config files

#49

Post by newobj » Mon, Jul 20, 2026, 7:32 PM UTC

if you get into a config system that's complicated enough, and has modularization or inheritance, you'll know that the semantics of "remove this" "add that", override this, default to this, this stuff is hard to express in most config languages, or worse, you start enforcing application level semantics. when you have turing complete language you just ... do those things. we reduced the configuration data of a tool suite once by 90%+ by moving from json to python. there was a tremendous amount of duplication and overlap, with tons of TINY exceptions and variations. it was so hard to see those differences, brittle to maintain, things would get stale, ... moving to python you basically had the "base" thing expressed in one file, and a bunch of tiny delta files encoding the exact deviations. All those deviations were of the forms I described above. Adding a thing to a list. Removing a thign from a list. Overriding a whole list. Do a thing if not already done. And so on. It's also then easy to build all kinds of diagnostics, validators, etc, right into the same framework, without having to munge the data into some other form first.

Re: Hyprland 0.55 announced the switch to Lua for its config files

#50

Post by Barrin92 » Mon, Jul 20, 2026, 7:36 PM UTC

>I have to ask…why do people want a Turing complete language to configure stuff?

because it lets me configure programmatically. Practical recent example, I use Wezterm which uses Lua as a config language but I tried out Ghostty and because I use all operating systems regularly I have a lot of 'if this then that' in my Wezterm config, different default shell, different key bindings etc. With Ghostty my only option is to maintain different config files per machine.

And what's worth pointing out is that Ghostty does have an operator for this('?' I think) which means there's already a bit of programming in it, except what always happens is that software with declarative config files invent their own scripting an templating languages as more and more people demand it, so just give me lua or lisp from the beginning and we're good.