Fennel is more popular than I expected! It's in the official repositories of Arch, Fedora and Debian.
It's a great great language, and fixes a LOT of the issues I have with Lua.
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.
I get that "sort of" was an attempt to hedge, but really, this isn't even close. Homoiconicity here would be if all javascript source files were valid JSON documents. A weaker version would be if it were common to use JSON to represent an arbitrary javascript program, but I've never heard of that, either. (For a good explanation of this weaker sense of homoiconicity, this stackoverflow page [1] is pretty good.)
[1]: https://stackoverflow.com/questions/31733766/in-what-sense-a...
To use Clojure as an example of a language that is homoiconic, you can take any Clojure source file, send it to an EDN parser (EDN being Clojure's equivalent of JSON), and not only will parsing succeed, but the result will be a complete representation of the program (you could execute it if you wanted to). In contrast, if you try to send JS to a JSON parser, you'll get an error as soon as it hits a function definition, or a for loop, or an operator, or whatever.
What they have is code parsed to a data structure, which is then susceptible to manipulation by the program before being executed. JS has some dumb textual eval, like the Bourne shell.
They also have the concept of a symbol.
And only one value that is false.
ES6 JS has nice syntax for calculating with lists:
let [car, ...cdr] = [1,2,3]
HMR is limited to modules (almost or always UI components), and there is no native VM support (module boundaries, side effects, and global state complicates it further) for it, and there is no multi-version coexistence either, and it is absolutely not suitable for production.
To call "hot module replacement" hot loading is very generous, and quite an overstatement.
It is only very superficially similar to hot code swapping. It is a developer tool, not a foundation for live, fault-tolerant systems.
It is absurd to call hot module replacement (HMR) "hot reloading". It might sound fancier, but it is nowhere close to true hot code swapping.
Peak redefinition of terminology. Call it what it is: hot module replacement, at best.
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.
Here's a thread a remember reading through at one point: https://news.ycombinator.com/item?id=26496339
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/...
Dynamic dispatch and the Object System are bolted onto the side and are still unparalleled by any language that I'm aware of.
I don't know if this is better for that use case, but even if not, luarocks is clunky and annoying to use at best.
- pixi.sh (docs) - lua package on the registry: https://prefix.dev/channels/conda-forge/packages/lua
1. Does this integrate natively with `package.path` and `package.cpath`?
2. Does it detect non-standard, popular installations like through brew(1)?
3. Can you install by GitHub `:user/:repository`?
Also, neat project! Nice work.
2. It defaults to using pkg-config to detect Lua installations and will fall back to installing Lua via the `lua_src` and `luajit_src` crates if it can't find them. We may eventually add support for other tools like vcpkg.
3. Not yet. It's on our roadmap to add support for that to our lux.toml/dependencies spec, but we probably won't allow rockspecs with that to be published to luarocks.org, because we don't want to be the reason people publish packages that can't be built by luarocks.
Thanks :)
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 ..
I've got some libraries that support five or six different versions of Lua. Building packages for all of them basically means throwing luarocks out the window, because linking to multiple Lua runtimes ti=o luarocks does all kinds of truly heinous things.
You can end up with the library and headers linked from different runtimes, simply because it isn't following what the local system says is available.
No, thanks.
Luarocks has its limits and probably should be rewritten, but using a language that fits the ecosystem and following the culture of the Lua ecosystem.
Rust and Cargo represent exactly the opposite of Lua.
To be honest, none of this is any different for python, or any of the other scripted languages which might be found ‘onboard’; however, one must always differentiate between the system-provided /bin/script_language, and one which might be being used as a development tool/scripting engine in a larger project, or indeed .. local tooling .. workbench.
One of the reasons I like Lua so darn much, is that its really easy and fun to get all the libs packaged up, bytecode linked, bundle wrapped up, and have a single-click install for your intended users’ operating system, quite effectively.
But yeah, you do sort of have to flex some limbs.
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
For example, how would I `lx add <dependency@version>` if the `dependencies` table might be generated by a Lua function?
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.
Not too hard. Emacs does it with the .emacs file, mixing generated and manual content.
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.
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.
For example, how would I `lx add <dependency@version>` if the `dependencies` table might be generated by a Lua function?
Lux defaults to TOML, but if you really want Lua, it also supports an `extra.rockspec` in the project root, which shares the same format as the luarocks RockSpec format.
But I would also accept that it would be a subset of Lua that could define tables, but not contain functions. The data only declarative sublanguage.
This is precisely the problem. If you allow runtime configuribility then people will do it. I don't want my engineers to even have the option to meta-program the configuration file.
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.
Additionally, I think there should be examples on the website of typical workflow(s).
Additionally, is "luvit" integrated in some way or another?
Additionally, does it work with LuaJIT? I assume it does, but worth a question.
- We're still quite early on in development, so documentation and things like error messages will need fleshing out.
- We don't have luvit integration yet
- Yes, it also works with LuaJIT, either via pkg-config or by installing LuaJIT headers using the `luajit_src` crate.
Are there any documentation on this?
luarocks works with luajit after I run that specific command, I expect something like that as it is very easy, so I wonder if running "lx path bin" would work.
Anyway, luarocks is easy to use, and is perfectly easy to integrate into most modern build and distribution tools.
However, Lua is everywhere, so of course: ymmv. Disclaimer: I’ve been using Lua for decades now, its Just Great™ in my opinion.
That said, luarocks is still easy to use, the problem is unmaintained packages.
I think moreso is the complete lack of any "batteries included" whatsoever. Not even something so basic as sockets are supported by Lua's stdlib. The ecosystem has had to fill so many gaps and a lot of that is dependent on Leafo and LuaRocks.
I'm hoping the great mlua Rust crate will help build the ecosystem since now it's mostly trivial to build easily-distributable native Lua packages in Rust.
As comments here suggest, lua isn't much of a bash replacement. Happy to hear your alternatives and suggestions for bash.
But yes, in theory, that might be nice! There's also the Python-powered shell, Xonsh, which I can't use either.
1 way to do things - not sure what you mean. It's a general purpose language, if you dont like something there's probably a different library that may do it the way you like (eg, don't like exceptions, use a library that mimics rust style Result values; don't like oop, don't do oop, functional programming is certainly possible in python), or easy enough to start creating your own private utility libraries that do things your way.
Xonsh was okay. Idk if I'd use it again. I'd probably just use python to invoke external cli programs using subprocess. I used xonsh for scripting before. I recall it having a slightly slow start up - I launch shell frequently so that's a no-go for me to use as my default shell.
---
And I looked at alternative scripting languages. Racket, D (has a single file script mode), ocaml, etc. Honestly python seemed good enough, even with its warts, especially with uv to manage deps without a whole formal project needing to be setup for a script. Stwp up from bash. Most of my use cases are fine with argparse + subprocesses + a unix shebang at the top + "chmod +x", with uv handy if I need a external library.
https://docs.racket-lang.org/zuo/index.html
Zuo is used to build Racket. It can be distributed as a single C file, which makes it extremely to integrate in new projects.
You have to reinvent the wheel every other day since the standard library doesn't come with much included
If you're stuck with the standard library (hello gsub!) and the application-specific library is an incoherent collection of functions, you're going to have a really bad time. That's the case too often because it's easier to plug the VM into an existing program than it is to create bindings that are not painful to use.
OTOH a well thought out environment makes you forget you're programming in Lua.
You'll need a glob function, cd/getcwd/setcwd, pretty-printer. That's about it.
Lua stdlib replaces sed, awk, grep, cut, tr, tail, etc.
Startup time is the best. In my testing, a lua script that functions like `echo` runs faster than echo.
the reason why it took so long is I use nixos and nix-darwin and... well, you know... it was non-obvious how to get everything working together "because Nix" but with the help of a good LLM I figured it out.
HOLY HELL IS THIS FAST.
i had the brand new chatgpt 4.1 rewrite a name=value pretty-printer terminal function from elixir (which I used because it was easy and maintainable, but at the cost of the VM startup) to lua.
272ms for the elixir version (`env | name-value-to-table`) vs. 17ms for the Lua version (`env | name-value-to-table-lua`). WOW. 1/16 the time LOL.
anyway here is that rewrite https://gist.github.com/pmarreck/47e110cbc62ea6603a0e61543d2...
Guess I'm gonna have to keep this in my toolkit! (And now that I figured out the Nix, it will remain easy!) Thanks!
this is kind of hilarious
lua must be severely optimized at this point
I'm sure there are plenty of libraries out there to rectify those issues, though.
(PS. I really cheer on Lua community having a decent package manager. Couldn't resist, though)
Cannot wait to see Lua come back in full force. I had used it ages ago to build World of Warcraft plugins, then came back with Roblox, then back again for AI.
I also recently released a server for Server-Sent Events [0] that is programmable with Lua. Overall it's been a great experience. The Rust mlua-rs crate [1] is trivially easy to integrate.