Show HN: Lux – A luxurious package manager for Lua

Fennel has actually convinced me that Lua and lisp have more in common than one might think. I don't know what the above comment was referencing, but I've always found beauty in lisp languages for having a primary datastructure that all others can be abstracted to. Lisp, classically, has list, clojure has sequences, and Lua/fennel has tables.

https://fennel-lang.org/

> Javascript is Lisp in C's clothes? On what basis?

On a lot of bases. Javascript has real lambdas, a sort of homoiconicity of code and data (hence JSON as a data format), also has the same dynamic take as lisps on "types belong to data". Rather than variables types belong to values. Brendan Eich's original idea was literally to "put scheme in the browser" and you can in fact pretty easily convert the Little Schemer to JS.

Saying two languages don't have much in common because they don't have the same syntax is a bit like saying we don't have much in common because we don't have the same hair color.

JavaScript is not Lisp but it is more like Lisp than like C, even though syntactically it much resembles C.

ES6 JS has nice syntax for calculating with lists:

   let [car, ...cdr] = [1,2,3]

Javascript hotloading development setups are about the closest you can get to the REPL development loop outside of lisp. I'd imagine lua is similar if the embedding is set up for it.

Lua is C in Lisp's clothing.

Lisp killer features were GC, good data representation, first class functions. Lua has all that and more. But its being a "thin" library over the C runtime shows through the clothes.

Also, I do want to point out that despite very recognizable syntax, that's not the only thing that makes lisp lisp. Primary example of lisp-y syntax on a non-lisp would be Janet [0]

https://janet-lang.org/

I have an intuition that the comment you're responding to has a lot of truth to it, but I am going to have to educate myself to give you an answer.

One thing I do know is that JS and Lisp both treat functions as first-class citizens, allow some degree of meta-programming, and rely heavily on hierarchical (e.g., nested objects in JavaScript vs. s-expressions in Lisp).

Passing functions by reference enables both LISP and JS to compose higher-order functions and, as suggested in another commented, both Lisp and JavaScript's "dynamic stack frames" somehow live updates to running code without requiring a complete restart of the application. The only clear example of this I can find, however, is Bun's --hot mode, which performs a "soft reload," updating its internal module cache and re-evaluates the changed code while preserving global state.

I have some vague notion that this is a favorite feature of Lisp, but it's not clear to me that it's unique to these language families.

---

Edit: Lexical scoping, closures, some tail-call optimization...

---

Edit 2:

> Programming language “paradigms” are a moribund and tedious legacy of a bygone age. (Dave Herman)[0]

---

Edit 3:

> The venerable master Qc Na was walking with his student, Anton. Hoping to prompt the master into a discussion, Anton said "Master, I have heard that objects are a very good thing - is this true?" Qc Na looked pityingly at his student and replied, "Foolish pupil - objects are merely a poor man's closures."

> Chastised, Anton took his leave from his master and returned to his cell, intent on studying closures. He carefully read the entire "Lambda: The Ultimate..." series of papers and its cousins, and implemented a small Scheme interpreter with a closure-based object system. He learned much, and looked forward to informing his master of his progress.

> On his next walk with Qc Na, Anton attempted to impress his master by saying "Master, I have diligently studied the matter, and now understand that objects are truly a poor man's closures." Qc Na responded by hitting Anton with his stick, saying "When will you learn? Closures are a poor man's object." At that moment, Anton became enlightened.

-- Anton van Straaten 6/4/2003 [1]

0. https://cs.brown.edu/~sk/Publications/Papers/Published/sk-te...

1. https://people.csail.mit.edu/gregs/ll1-discuss-archive-html/...

Useless if you need to run it in a scripting environment where you don't have control over runtime too. The thing lua was designed and is still prominently used for.

> pkg-config to detect Lua installations

I have a strong opinion on this, as a Lua developer with some experience shipping Lua code.

Good third-party package management for Lua should function independently from the system-provided Lua installations.

It’s all too easy for newcomers to the Lua app-development world to tie themselves into some “auto-detected Lua” path that is, frankly, bonkers. It makes things hard to ship.

If you’re going to write a Lua app, and want to manage your Lua dependencies - use ‘luarocks —local’ and leave system-provided resources out of the picture.

Bundle Lua up front.

This is true of python, also: if you’re going to try to build an app that uses either Lua/python, one must take responsibility for building and bundling locally, and not using system-provided lua/python bindings.

Sure, use “brew —-prefix lua” to get things started, if that has to be a thing. Use pkg-config too, to build the “System/Package-Manager provided” lists.

One of the best practices for luarocks is to know and use the —-local flag with gusto and bravado, and include its artifacts in a larger app build/bundling target. This can be done in a cross-platform manner for all of the major platforms. Having a build target with a successful ‘luarocks —local’, for a locally built Lua and dependencies, does indeed rock. You can put everything in a .local/lua … and treat it just like any other linkable object resource.

If there is one solid rule for effective Lua development, it is: leave the system Lua’s alone, and build your own .local/lua tree, properly.

If you can’t do that, you’ll be missing out on the grand prize: being able to ship Lua with certainty that your Lua bundle will work, regardless of whats onboard the users’ setup … which is, after all, kind of a holy grail of the language, and therefore also a priority of its package management tools.

Another “Lua dev maxim” is, there are many Lua’s. There are reasons to use Lua 5.1 in a project - and reasons to use 5.4 and LuaJIT, too. Switching Lua’s is why I luaenv, but also, you can bootstrap a fresh Lua with CMake real fast, either as a project tool/binary, or directly to the VM abstractions, integrated into your app. A great Lua project has Lua 5.4 in the project, and both developer and end-user host binaries which include a Lua 5.4 environment, sandboxed, built from exactly the same sources. Bonus points for the Desktop/Mobile bridge getting crossed ..

So, depending on a system Lua, is repeating the same mistake prior lua package managers made, maybe. I have reached nirvana with luaenv+luarocks+cmake, personally.

I’m not suggesting lux not try to be self-aware on the basis of finding system standard tooling and libraries for its purposes, but that to be better than luarocks, lux will have to be able to handle —-local builds just as well ..

Luarocks is not just about being a ‘pip for Lua’, its also about having everything relatively tidy to support a fully local build and packaging target. With luarocks you can not use the system Lua, entirely - and that is a pretty significant use-case for luarocks, its utility in the packaging steps ..

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

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

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

Load the table. Modify. Serialize to file.

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

What variability? Lua can be easily sandboxed to not take any inputs: Running it would express the same manifest. And most Lua configurations would still read declaratively unless they needed extra the complexity.

I just think it's a shame that the manifest file for Lua projects would be in a language other than Lua itself. I'm more sympathetic to other trade-offs, though, such as being able to edit the file mechanically.

https://en.m.wikipedia.org/wiki/Rule_of_least_power

You just described in a concise way why I feel like “simple non DRY terraform configuration” is much better than “insane variable indirection to avoid like 20 lines of copy pasted code”

Configs are configs. It’s better for them to be obvious and verbose than it is for them to be hard to understand and pithy. They don’t have the same requirements as the software that actually goes out on the release train.

It works for Elixir, really well I may add.