Live data from Hacker News

Hyprland 0.55 announced the switch to Lua for its config files

hypr.land

81–90 of 146 posts

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

#81
It's neat that Hyprland lets you define layouts in its config but I like niri's approach.

It uses KDL (an established document / config language) and slightly extends it to add useful things like being able to include files.

For example, here's mine: https://github.com/nickjj/dotfriedrice/blob/master/.config/n...

What you end up with is a config file that's natural to read with no prior knowledge about anything and if you want to look something specific up, you know it's officially documented and not some home grown pattern someone created. There's a certain amount of comfort and stability you get with a "what you see is what you get" approach.

I never felt like I needed variables, conditions, functions or loops with niri's config.

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

#82
post #76
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.

> 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!

GN tool that is used in Chromium to generate ninja files has much more restrictive language than CMake or make. And even its more complex features are mostly workarounds or escape hatches to deal with legacy setups.

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

#83
post #72

Earlier quoted context omitted.

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.

You actually can define custom functions as named templates, but they're definitely not pretty, and would almost certainly push you towards the "just allow us to write code using a normal programming language" side of the argument.

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

#84
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 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…

> With Ghostty my only option is to maintain different config files per machine.

This turns out to be a benefit IMO.

Ghostty supports include files. You can have all of your shared config in 1 main config and then have small files that are included which are machine specific. My dotfiles uses it and it supports Linux and macOS. Example: https://github.com/nickjj/dotfriedrice/blob/master/.config/g...

You can have something like this in your Ghostty config: config-file = ?config.local

And then on each machine that's different, you can have your machine specific config in ~/.config/ghostty/config.local or whatever you decide to name the file.

It works out nicely because config options are merged, so the local file can overwrite what's in the main config. This lets you deviate from the original git committed config without needing to modify it. Super handy for public dotfiles.

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

#86
post #58

It's just part of what I call the config pendulum. Simple config -> (Need to do more complicated things) -> Add override levels -> (Need even more flexibility) -> Add a Turing complete language -> (Things get ridiculous, lots of spaghetti code outside of version control. Time for a reset) -> goto "Simple config" It's fine. I am not saying it's wrong or right. I've gone through the cycle a few times in some projects.…

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

WirePlumber switched its config from Lua to a JSON variant not so long ago.

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

#87
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.

> Python setup.py -> pyproject.toml?

That's because setup.py was objectively a mistake. In order to know how to run the package you need to know its dependencies, which requires evaluating setup.py, but you cannot evaluate setup.py until you know the dependencies, which requires you to evaluate setup.py, and so on. The pyproject.toml is plain text where you specify the build backend and its options, and the build system can be as complex of a program as need by.

If anything, pyproject.toml is an example of taking the idea of programmable configuration to its next conclusion. The build system is part of the configuration and it's more than a simple script, it's an entire application. You just plug in its name into the universal entry point pyproject.toml.

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

#88

I wish there was something better than Lua and just as "obvious" a choice. Static types, real arrays, zero-based indexing, etc. Closest thing I've seen so far is Roto: https://roto.docs.nlnetlabs.nl/en/stable/index.html Basically everything about this looks great - Rust-style syntax, static type checking, sane type system, easily embedded. The only slightly odd things are that it has built in types for IP addresses,…

The language is primarily used by Rotonda, the composable, programmable BGP routing engine.

Not odd to have those data types at all…

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

#89
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 have to ask…why do people want a Turing complete language to configure stuff?

What's the alternative? Petition the maintainer to add every little feature any random user might want? Or just do it yourself in a few lines of code?

Case in point, when I was still using BSPWM I did no like how if there was only one window on the desktop it would still get an outline. So I wrote 14 lines of Awk (BSPWM lets you use any language) to get what I want. This was only possible because BSPWM gives me all the primitive building blocks and lets me go wild with them. Sure, if all you want to do is set a few colors and numbers that's overkill, but any power user will sooner or later find himself thinking "oh, if only I could do X when Y unless Z".

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

#90
post #58

It's just part of what I call the config pendulum. Simple config -> (Need to do more complicated things) -> Add override levels -> (Need even more flexibility) -> Add a Turing complete language -> (Things get ridiculous, lots of spaghetti code outside of version control. Time for a reset) -> goto "Simple config" It's fine. I am not saying it's wrong or right. I've gone through the cycle a few times in some projects.…

That's clever insight. If it was lisp from the beginning, maybe would be more straightforward. It's as simple as code can get, according to Uncle Bob, while still being expressive. It's no wonder Emacs still reigns supreme. Well, I am happy with Niri's kdl approach for the time being.
Post reply on HN