Live data from Hacker News

Hyprland 0.55 announced the switch to Lua for its config files

hypr.land

71–80 of 146 posts

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

#71
post #6

I have grown pretty negative opinions of “using a programming language as a config language” after semi-recently having to spend a lot of time screwing around with someone’s Gradle Groovy abomination. Not even to mention how quickly Nix can get annoying. I have to ask…why do people want a Turing complete language to configure stuff? I use Sway personally, which is very configurable but for any even remotely complicat…

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.

I mean, fair enough I guess. I've accidentally more-or-less reinvented interpreters on two separate occasions (both times using JSON as a quasi-AST), so I understand it.

I guess I just feel like if you feel like you need programming constructs in your configuration, its approaching it from the wrong angle, and it should instead be handled via plugins.

I feel like configuration itself should be a "dumb" format like JSON, and when you want to do anything that can't be accomplished by plain JSON, you should allow for easy development of plugins.

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

#72
post #65

Earlier quoted context omitted.

I haven't really seen program go back from "a programming language" to a simple config format.

Python setup.py -> pyproject.toml? Make -> ninja. eBPF kernel modules from C to a custom language. Helm Go templates -> Kustomize. I am sure there are other projects picking up json from a previous xml + xpath + other ...xml junk.

I'll die on the hill that Helm charts are more of a problem because text/templating is a weird looking templating language then anything else.

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

#73

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. https://dwm.suckless.org/customisation/

Requiring a C compiler, source code and header files to change your keybindings is just a different kind of bloat, and nothing can change my mind.

Then I won’t try! And I understand your opinion. But like everyone else I have many programs using many different configuration syntaxes, some using more than one file, some files in nonstandard locations, and some combining configuration from one or more files in my user directory with others somewhere in /etc or who knows where. I find the dwm approach refreshing.

Pontification added later: And it has a beneficial side-effect. I’m not much of a C programmer these days (if I ever was), but I found I was able to understand the dwm code well enough to make some small changes in behavior. So the dwm approach encouraged me to go beyond changing definitions in the headers. (This is aside from 3rd party patches. I was even able to contribute one of those.) This is really in the spirit of free software.

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

#74

Earlier quoted context omitted.

If you look at hyprland config, you can see why they went with it. Much like vim/neovim config, people want to do things like register a callback that fires to determine the window title and things that are much more advanced than that, like layout management. When I was using sway, I was using its IPC or worse ( https://github.com/johnae/persway ) to do advanced things, and Lua scripting in the first class config wo…

That feels like a plugin or external program, not configuration

[deleted]

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

#75
post #72
post #65

Earlier quoted context omitted.

Python setup.py -> pyproject.toml? Make -> ninja. eBPF kernel modules from C to a custom language. Helm Go templates -> Kustomize. I am sure there are other projects picking up json from a previous xml + xpath + other ...xml junk.

I'll die on the hill that Helm charts are more of a problem because text/templating is a weird looking templating language then anything else.

Or to be more specific, issue isn't text/templating as such. It is a fine templating language for text.

But to use a text templating language to generate YAML, which is not only structured, making it a bad match for character based templating with no knowledge of syntax, but indentation-based, making the combination almost seem like a joke.

Helm charts must be the worst engineering solution I have seen in popular use. First time I saw it I didn't believe it, that this was something people did, for real.

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

#76
post #65

Earlier quoted context omitted.

I haven't really seen program go back from "a programming language" to a simple config format.

Python setup.py -> pyproject.toml? Make -> ninja. eBPF kernel modules from C to a custom language. Helm Go templates -> Kustomize. I am sure there are other projects picking up json from a previous xml + xpath + other ...xml junk.

> Make -> ninja

I would disagree on that one. Ninja config might not be turing complete, but they're generated by turing-complete tools (usually cmake). Nobody writes ninja by hand, thus I would argue it's irrelevant!

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

#77
post #6

I have grown pretty negative opinions of “using a programming language as a config language” after semi-recently having to spend a lot of time screwing around with someone’s Gradle Groovy abomination. Not even to mention how quickly Nix can get annoying. I have to ask…why do people want a Turing complete language to configure stuff? I use Sway personally, which is very configurable but for any even remotely complicat…

It is good to keep a configuration simple enough that it doesn't need to be a programming language. The absolute moment you find yourself thinking of putting conditional logic, or string substitution, or anything like that, in your pure config format, switch to a real programming language, before you end up managing several times the complexity of one with only some of the benefits. No need to end up contemplating so…

> The absolute moment you find yourself thinking of putting conditional logic, or string substitution, or anything like that, in your pure config format, switch to a real programming language, before you end up managing several times the complexity of one with only some of the benefits

That’s where you add a plugin system or an ipc mechanism, not a whole programming language.

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

#78
post #4

TIL I'm on 0.56 and hadn't realized there is a change. Thinking I'll wait as long as I can and then just get an LLM to translate current config to lua once the internet has been seeded a bit with examples

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

Nice. I'll give that a go. Pretty vanilla config so fair chance it'll work

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

#79
post #72
post #65

Earlier quoted context omitted.

Python setup.py -> pyproject.toml? Make -> ninja. eBPF kernel modules from C to a custom language. Helm Go templates -> Kustomize. I am sure there are other projects picking up json from a previous xml + xpath + other ...xml junk.

I'll die on the hill that Helm charts are more of a problem because text/templating is a weird looking templating language then anything else.

I wouldn't say text/template is terribly weird per se, and it's quite reminiscent of Jinja. But what is awful is using a text templating language to generate yaml with the correct level of indentation, and that's where 75% of Helm's problems lie; the other 25% is putting too much logic in templates while working with the clumsy workarounds to text/template having no capability of defining custom functions.

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

#80
post #6

I have grown pretty negative opinions of “using a programming language as a config language” after semi-recently having to spend a lot of time screwing around with someone’s Gradle Groovy abomination. Not even to mention how quickly Nix can get annoying. I have to ask…why do people want a Turing complete language to configure stuff? I use Sway personally, which is very configurable but for any even remotely complicat…

I would agree that turing-complete config is more trouble than it's worth when the config is something you might need to reason over, such as a build definition in Gradle. But for something like a window manager config where everyone's config is a snowflake, it's kind of ideal. Horses for courses and all that.
Post reply on HN