Hacker News Reader

Comment by Arch485 | Hacker News Reader

Why not use Lua for config instead of TOML? IIRC Lua was originally a data schema language, so it should be good for it.

View on HN

Is there a good reason to introduce the halting problem to a package manifest?

Lua has a sandboxed runtime so couldn't you kill rogue scripts after a timeout?

Would you rather do that or use toml?

Lua was designed for configuration, so I'd rather use Lua. Plus, it makes for a more elegant, unified design. TOML, and friends, are better paired with languages that were not designed for configuration.

It seems like every new language community and generation of developers needs to re-learn a set of the same lessons (why declarative instead of imperative config is the way to go, why functional is superior to imperative, why immutable is superior to mutable, why TDD (or just unit testing) is important, why hexagonal design is the best organization of logic, why static typing is important, why Nix is the only valid global package manager, etc. etc. etc.) and I suspect it's because these problems all share the same attributes:

1) the inferior solution seems easier at first (but won't be in the long run)

2) the people blithely picking the inferior solution have not yet encountered enough of the thorny nastiness that the initially-harder option completely prevents

the end result being that all the "greybeards" have settled on the "initially harder" solutions for things because they all learned the hard way that it just causes less headaches in the long run

I know what lua was designed for and have professional experience with it. It's not that great as a config language imo, I can easily understand why a project would use something else.

With Lua, it becomes near impossible for a program like lux to edit the manifest.

For example, how would I `lx add <dependency@version>` if the `dependencies` table might be generated by a Lua function?

Indeed. I'm glad for us to have learned Python's 20 year lesson on the dangers of an executable manifest.

The Zig language seems to have learned the lesson the other way though: https://ziglang.org/learn/build-system/

Isn't build.zig.zon the equivalent of the manifest in that case though?

Sure, but a zon file is really just an anonymous zig struct.

With the disclaimer that I know nothing about zig, I will say that Nix's flake files follow an interesting pattern where the output section is evaluated under the regular Nix interpreter and can do anything, whereas the input section is evaluated under a far stricter mini-interpreter that prohibits everything other than basic strings and attrsets (dictionaries).

A flake.nix is certainly not packaging metadata, but I do know those input section restrictions do cause occasional confusion with users who think "ah, Nix code" and only realise afterward that it's really json in Nix syntax."

All that to say, if a thing is not evaluate-able, it's probably best to represent it in a different enough form that no one could mistake it for a thing that can be evaluated.

Why not use a function to add dependencies, e.g. `add_dependency "dependency@version"` or `add_dependencies { ...table-here... }`. This is, more or less, how premake works [1]. For `lx add ...` you'd append the function call to the script.

[1] https://premake.github.io/docs/Your-First-Script

That doesn't seem very ergonomic - especially for the use cases we have in mind.

Load the table. Modify. Serialize to file.

Not too hard. Emacs does it with the .emacs file, mixing generated and manual content.

> Load the table

If it comes from an impure function, you don't know if you'll get the same result each time you evaluate it.

> Modify. Serialize to file.

And potentially lose information.

Reply on news.ycombinator.com