I think a lot of people complain about Lua because they are trying use use it as a Python alternative. Lua and Python are suited for very, very different tasks.
If you are whipping up a command-line script because what you want is too complex to attempt in Bash, use Python. Lua is terrible for this.
If you are making an application from scratch using just the stand-alone interpreter, your scripts and a bunch of dependencies from the internets, use Python. People work really hard to make this semi-viable in Lua, but it is a path of frustration.
If you have your own C/C++ program and you want an easy path for configuring and composing features that are written in C/C++, deciding between Lua and Python depends on your goals.
Do you want MAXIMUM POWER for the scripter to whip together any crazy feature they might dream of? No concerns about footguns, hanging ropes or corner-painting? Memory and performance are secondary concerns to flexibility? Go use Python!
Do you want minimum power for the scripter so as to keep their creations constrained within a defined box? Is there a pre-defined role that the script will play? Are there definite restrictions on what should and should not be done in scripts? Are you going to be responsible in practice for debugging some monstrosities that the scripters build for themselves? Are performance and memory primary concerns above flexibility? Then Lua is well suited for embedding into your application.
> If you are making an application from scratch using just the stand-alone interpreter, your scripts and a bunch of dependencies from the internets, use Python. People work really hard to make this semi-viable in Lua, but it is a path of frustration.
It's unfortunate that Lua doesn't work well for this. The Lua implementation's light weight, portability and robustness [0] seem ideal for building these applications - especially for building applications that can be distributed to end-users (a scenario which is not a focus of Python [1]).
Obviously Lua is never going to include a large standard library because that conflicts with its embeddability. However, even in the Python community, “batteries included” is no longer considered entirely beneficial [2]. Instead, I think Lua would benefit from a set of officially recommended external libraries. This would improve the situation for people trying to write standalone applications in Lua, and I believe it would also help those who are writing scripts targeting embedded interpreters.
Having a set of "blessed" libraries has definitely been discussed on the mailing list. Also there are plenty of "distributions" like Lua for Windows[1], LuaPower[2], or runtimes like Luvit[3] that add features ootb.
That said - the Lua ecosystem in 2021 is not the same as it was in 2005 or whenever people compare it to. There is a healthy amount of Libraries and choices of libraries for solving most tasks on Luarocks. And I would suggest you produce a better end project by selecting which libraries are included in your project that uses Lua for scripting. You can even further remove your choice of the libraries that _are_ included ootb.
I'll add one other point which is that in memory constrained platforms Lua is unrivaled in its ratio of power/memory footprint.
Back in games we put the whole game state (including ai routines written by designers using coroutines) in a 400kb preallocated block on a system that had only 8mb of system ram. Worked like a champ.
The classic Doug Lea's Malloc with #define ONLY_MSPACES is great for this. That way you can constrain not only Lua's memory usage, but also it's fragmentation.
We'd also manually run a fixed number of GC steps per frame in our games. The higher average CPU use was worth the much lower variance.
> If you have your own C/C++ program and you want an easy path for configuring and composing features that are written in C/C++, deciding between Lua and Python depends on your goals.
And to expand on this, it's easier to add features to a language than to remove them. If one's design requires certain runtime constraints (ability to hook into interpreter execution and memory allocation, no per-process global restrictions), packaging (e.g. static linking), and ease of portability, then starting off on the minimal side (Lua) is better than trying to strip things off of a larger (Python) runtime.
You can also get to a middle-ground state between "no batteries" and "just enough batteries" to get a large portion of the expected work done if the problem space is understood and has some bounds. E.g. including a library to make HTTP requests, parse JSON and work with an embedded SQL database will be enough for a lot of use-cases in the "user-defined glue logic on an existing application" space.
Yes, this. We use Lua for embedding and even the few batteries were more than we wanted. We stripped out file and network I/O and some other stuff I can't remember right now.
"Batteries included" doesn't mean you have to _use_ the included batteries... or like Lorenzo Donati says in the article:
> "But no one is suggesting that a set of batteries become a requirement for Lua—even the existing Lua standard library can be compiled out for use cases where it is not needed"
Sure, yeah, you can try to make future Lua do both what current Python and current Lua do well. I, personally, don't see the appeal, because Python already exists - the only reason I use Lua is that it fills a niche that Python doesn't.
It's great at filling that niche but if I want something like Python I just use Python.
Serious question since you have familiarity here. Why not something like Wasmr instead to provide the runtime hooks into your code and letting the user pick whichever language they want?
I have not dug into WASM myself. But, I've heard there are multiple implementations out there that are very nicely embeddable. They might well be good competition for Lua. I guess I'd ask a few different questions. Who is your target audience? Are they professional coders or semi-technical users? Are they in-house or are the customers in the wild?
If you have in-house coders who can't agree on what language to use, I guess WASM could allow them to agree to disagree. I'm not sure if that's a better path than using the languages' native tools and focusing on improving the compile-debug iteration time.
If you have external coder customers who will demand differing languages, WASM sounds great!
If you have external, semi-technical users who don't flat-out demand JavaScript-or-Die, standardizing on either Lua or Python is probably better for them both in terms of complexity and consistency of documentation and community help.
In general, for semi-technical users, see my above post on power levels.
I personally DO use Lua sometimes to code general purpose stuff.
Still, I don't see Lua ever having "batteries", the language wasn't invented for that purpose, and the original sponsor of the language wouldn't want it changing in that direction (I dunno if they still sponsor it though).
Lua was invented by PUC-Rio (Catholic University, Rio de Janeiro campus) at the request of PETROBRAS, its purpose was "describe" stuff, and replace another language that they already had, plus being turing complete, because they got tired of hacking things endlessy whenever they needed to describe something "new" in their systems.
So to "describe" stuff, Lua doesn't need libraries.
That said... currently Lua most popular use is add some kind of scripting environment to other software, still that often means a library would be useless, and even then sometimes that usage is still to describe things, for example the game "Crusader Kings 2", use Lua to read a file named "defines.lua", and all it does is set some constants, another use of Lua that I find interesting is "xmake", Lua programs in it are very descriptive, using Lua syntax features to "tell" things to the system, instead of looking like anything resembling a normal imperative program.
EDIT: about community size... yeah, it is tiny :( I never found a Lua job, companies that use Lua often hire a programmer of other languages and teach him Lua, I am also currently using PUC-Rio official GUI library (iup) and never found anyone else using it to ask questions about it, I've been in PUC-Rio during a tech event, and when I asked around if anyone knew where Lua authors were, the people that study and work there, didn't knew they had anything to do with Lua in first place!!!
Nice info there. I recently started using xmake and for someone who is spoilt by npm, cargo and nimble i was really impressed by xmake. I finally dont have to write Makefiles.
Lua is a very good choice for config files. Wezterm uses lua for configs. Lite editor uses lua only plugins and configs. And many more. Maybe someone/group of people can step up and declare an universal config format using lua for everyone.
As for batteries, I would love to have that but wouldnt that again defeat the whole purpose of Lua as embeddable? But of course people would love to have it.
It's a statically typed dialect of Lua, which is compatible with all modern Lua versions.
The core compiler itself is one tl.lua file which can be added to any Lua project, and includes a Lua package loader that makes Lua's `require()` support .tl files, and there's also a tl CLI for generating .lua from .tl files.
> So to "describe" stuff, Lua doesn't need libraries.
Maybe you can clarify what "describe" means. It reminds me of the subtle-possibly-false dichotomy between a program and a configuration. Turing-completeness could be one way to think about that dichotomy it, but in this case Lua is definitely Turing complete.
In any case, if there's commonality to the stuff being described, then that's the kind of thing that is "batteries". Sequences, associative arrays, etc. come up all the time, and that's available. Surely there are some things that come up a bit less often when describing systems, though I don't have a concrete example on hand.
My main question is, since any program is a description of a computation, then what kind of distinction are you making?
I started typing a really long response here to address many of the comments I have been reading. In the end, it was becoming a huge wall of text, which is not something that I think this site is suitable for. So, I wrote a blog post about it instead:
I'm speaking from the point-of-view of someone who used Lua for games, hardware, and web, in there. I am not an expert in the language, but I feel that many people here are approaching the language with the wrong perspective, and thus are unable to see what makes it great.
All I write there is my own personal opinion of course, I'm totally OK if you still hate Lua after reading it, but I'd encourage those here who have criticism about it to double check my article and reach out if they want to talk more about it.
I use Lua daily at work for implementing new features for our robot offerings.
One of our motion equipment suppliers had an existing set of products for industrial automation which were originally programmed in C++, but also offered a more standards compliant version for doing PLC programming.
My employer negotiated very early on ( pre 2000 ) for them to provide a simpler interfacing layer, and we got Lua libraries as a result.
Now we do the bulk of our automation equipment programming using a fully featured Lua library, which interfaces with the core controller/amplifier/motor/sensor/IO libraries already present on their original product.
A sizeable portion of our equipment now are programmed purely in Lua, and we work closely with said supplier so that they update the library when a feature deficiency is noted.
Wish I could say more about it, but you can count me in the group that enjoys programming in Lua, and does it daily.
I'm not using it for general purpose software, its for a highly specific use case that is tied very tightly to proprietary hardware unavailable for purchase without purchase contracts, so this is very different from what normal programmers might have to deal with.
As someone who's barely used lua (only when forced to), I dont get it.
There error messages aren't great, the 1-indexed arrays, the syntax is super weird.
I understand there is good technical aspects to the language, but I am really thrown off by the syntax. I get that that could go away with time, but I have no reason to believe that "learning lua" would actually bear any fruit.
Part of me is convinced that Lua is liked simply because it's unpopular, and that if it was used in production more, people would hate it. Kinda like we hate javascript and c++. Maybe it's that we hate our jobs, and blame the language, and then we go home and screw around in lua, we enjoy ourselves and blame the language.
EDIT:
Just to piggy back on my comment here:
I've been optimistically looking at the wren scripting language. That seems like the "correct" way to make a scripting language, at least from the outside. I should make it clear that I am not speaking from a position of authority, but I am sharing my opinion of LUA as a pessimistic outsider, which I think is very common view.
Having used Lua a fair bit in the past year (in order to write custom plugins for Kong), the main draw (and in some cases, drawback) for me with Lua is its integration of coroutines. Draw as it makes writing event-driven code dead simple, with coroutines managed behind the scenes as you write code serially. Drawback as if you pull in the wrong library, one that does something in a blocking fashion (such as with a c module that doesn’t “get” Lua), you can get into some trouble.
In terms of syntax it’s basically JavaScript with stupid array indexing, which is enough to turn people off I’m sure.
IMO Lua's main strength is its implementation, not the language itself. Compared to Python, it's more performant, lightweight, portable and robust [0].
Unfortunately, the language itself is "quirky" at best. Its has unusual syntax, variables that are global by default, and pervasive use of `nil`. I personally also dislike build-your-own-object-system and the language's conflation of lists and maps.
I too have been looking for an alternative to Lua - I want a language like Python with an implementation like Lua's, which I could use both for embedding and standalone command-line applications. I've even considered building something like this myself - either from scratch or, perhaps, as a fork of MicroPython.
No language has _great_ error messages. But comparing the Lua message for e.g. `print(nil+5)` to the Python message for `print(None+5)`, I somewhat prefer Lua's natural language approach "attempt to perform arithmetic on a nil value" over Python's jargon-heavy "TypeError: unsupported operand type(s) for +: 'NoneType' and 'int'". Of course Lua's message could be better (it could/should tell you which operation and where the nil is in the expression), but "not great" basically describes every language's error messaging, and Lua's messages are not exactly eye-bleeding like C++ STL errors either.
> the 1-indexed arrays
1-based indexing is actually really human friendly, and programmer affinity for 0-based indexing in languages that don't map directly to RAM pointer offsets is largely excess familiarity with C plus cargo-culting and wanting to believe that everything Djikstra ever said is universally true regardless of context. Indexing by 1 gives many nice human-oriented properties, like for instance that indexing the front and back is symmetrical (first is 1 and last is -1), whereas in 0-based languages you have 0 and -1 which makes a lot less sense (people who haven't been bent to the will of the C language gods don't think of the last element as one before the first one, it's all the way at the end) except as a conceit to the fact that there's no -0 available. It's easier to reason about a list of five things where the first element is the first and the fifth element is the fifth, instead of constantly having to do mental -1 arithmetic to satisfy a paradigm that requires visualizing hardware memory layouts.
And if you really really really want to cycle over an array using modulus operations, the classic "0 is better" example that people love to trot out, Lua also lets you start your array at 0 if you want. Lua doesn't care what you use for table keys as long as they're not nil.
> the syntax is super weird
Is it? I teach Lua to people, and most novice programmers I meet find the syntax quite intuitive with its plain english keywords and operators. Do you think "function" is more weird than "def" or "sub", "or" more weird than "||", "not" more weird than "!"?
I was almost going to argue with you, but Rust takes pride in actively developing and improving error messaging and it is strongly to their credit.
So instead of "no languages" let's instead say "very few languages, and none of the top 8 languages according to TIOBE". (Rust is now #9 as of like just now when it was #18 a year ago, so mad props to them for breaking into the top 10!)
I love that example of the lua error message, but aren't there non-arithmetic functions that also error? What's the message in that case?
What's nice about Python's message is how compositional or "orthogonal" it is, which means that the errors can easily be handled in a program. Does Lua have anything like that? From the manual
> If you need to handle errors in Lua, you should use the pcall function (protected call) to encapsulate your code.
This actually helps me understand a bit the dichotomy between "configuration" and "program", and why Lua is so good for the former. As another comment put it, it's good when you need to "describe stuff". It doesn't make a lot of sense to describe something that handles errors in its own description, which motivates relegating error handling to specific contexts.
Languages exist in a technical space, but also in a social space. The single largest reason I can think of that Lua is known is because World of Warcraft used it as the UI language, and therefore a critical mass of people had to learn it to do a popular thing. Kinda like how it's irrelevant how good or bad JavaScript is if it's the only way to get dynamic behavior in a web browser.
... and in terms of why Blizzard used it in WoW... One of the strengths of Lua is it's so small that its interpreter is extremely easy to understand and debug, while still having just enough power to make most things one wants to do not super irritating. That's the technical-space aspect that boosted its social-space aspect... It's not so bad to use that nobody wants to touch it, but it's so simple to integrate into an existing complicated system that developers aren't pulling their hair out building the integration layer to whatever they're really writing the system in.
The Lua implementation was definitely its strong point, and LuaJIT is reportedly extremely good as well. I say “was” because the circumstances have changed and there are much better alternatives around.
Circa 2000 or so, if you wanted to stick a simple, self-contained language in your app for extensions and scripting, Lua was one of the very few reasonable choices. There are a ton of reasons why you might not want to stick TCL, Guile, or Python inside your application.
So Lua was used not only in the WoW UI but in a bunch of other apps from that era, and gained a lot of social traction that way. Among other things, if you were making a game, Lua let your level designers and UX people write a little bit of code without having to get their hands dirty with C++ (which nobody wants). The language is very off-putting otherwise.
This is gonna be subjective, because it depends on what your priorities are.
The two alternatives at the top of my list are Gravity and Wren. They are both designed for the same general profile that Lua has—a scripting language, safe to use, embeddable, with a small VM (low code size).
> Lua was one of the very few reasonable choices. There are a ton of reasons why you might not want to stick TCL, Guile, or Python inside your application.
That sounds quite editorial - can you list some of the “ton of reasons”? C. 2000 Tcl was already 12 years old, received a major performance upgrade w 8.4[0], and was liberally licensed.
It seems like people have forgotten how bad TCL is, as a language. Everything is a string, except variables, which can be arrays of strings. You want a number? String. You want an object? String. You want a data structure? String.
TCL is a bad choice for almost anything. It is only marginally more usable than using a shell. It seems like the only reason you would use TCL is so you could throw together a GUI in front of a command-line program, or maybe stick a very bare-bones scripting interface inside something else.
I wrote a lot of TCL code in 2015-2017, and it was better than I thought going into it. TCL has first-class lists and maps, and they're not string-based under the hood at all. It's true that TCL was "all string all the time" in the early days, but now it's more like Python - you represent those types as a string, but that's not the internal storage.
I think TCL gets a really bad rap. Once you get past the unusual syntax, it's pretty nice to work in. Almost Python level nice. It supports classes, exceptions, first-class functions, and has some concepts I've never seen in other languages (such as upvar). It's easy to embed, or easy to use standalone. Installation is small and portable. And it feels like if Lisp and Bash had a baby together, conceived with love.
TCL in 2005 might have been a beast. TCL in 2020 is way better than you might expect. And it persists also, with a stable ecosystem as an embedded language in various CAD/EDA tools.
So, I like Lua as a language, but I think that Janet, 5 years down the road, will be a better fit for a "Lua+Batteries", for people that can stomach parens. It's already well on it's way there now.
It takes like 10 minutes to learn Lua's syntax. You can literally stumble through it with [1] the tl;dr
.. is for concatenating strings
~= is not equal to
The way it handles closures is beautiful and extremely powerful. Lua is a Scheme in FortranScript's clothing.
I like your theory of unpopularity, that statement is always true in some capacity for esoteric things, liked this are also liked because they are popular. My favorite posts are the ones that are like yours BUT they continue to use it because it is the best tool for the job. Thats when you know it is true.
I believe there is value in learning Lua, and reading Programming In Lua in particular, early on. It's object and inheritance system is in your face. I feel learning it afforded me a more intuitive understand of prototypal inheritance systems.
Lua’s object system is in-your-face and in my personal experience very difficult to use. I found it very difficult to reason about basic questions like, “Is my Lua wrapper for a foreign object safe?”
Prototype inheritance is kind of nifty but I would really like an escape hatch to be able to avoid using it, mostly for wrapping foreign objects.
I have mostly the same feelings, though my only experience is with WoW and Payday 2 addons.
A big gripe of mine is there's really only one namespace. If something is exported, it goes to the aether and everything can see it, making it very difficult to track where variables are defined and modified.
That's like complaining about braces vs begin/end. It's just a non-issue, has been standard on other popular languages, and it's just a convention to get used to.
I'm surprised there was no mention of Penlight in that article. Penlight, a supplemental standard library for Lua that is heavily inspired by Python's own standard library, has been around for years now:
Python is extremely popular in education and I'm convinced this is a huge part of its overall popularity. In that, it displaced Java in a move wildly popular with students; the language designers practically targeted college classes. But professors are conservative and won't usually change languages unless there is a compelling advantage.
So, you might think Lua can't compete with Python in education. But we have an ace in the hole: concurrency. Lua can be a great sandbox for learning concurrent programming, with built-in coroutines and a reentrant interpreter on top of an extremely simple semantics and basic type system.
The problem is that nobody is going to want to use an ad hoc combination of Lua and some questionably maintained 3P libraries to teach a course. If Lua is to be useful for teaching parallel programming, it needs a built-in or at minimum endorsed solution for parallelism. Penlight, probably the most popular "Lua batteries" collection, includes almost everything except parallelism!
Another issue in education, though, is 1-based arrays. They're a minor annoyance in practice, but learning to count from zero is important in many CS courses.
Real regex would be nice. I understand not going full beans with the batteries, but surely a few more wouldn't go amiss? Perhaps a 'battery' for formatting a Lua table as a string, since tables are such a big deal in Lua? This would help immensely when debugging scripts during development.
For more complex string matching tasks that the built-in patterns cannot handle, LPeg might be a good choice. I think it's not likely that something like PCRE-compatible regular expressions would be included in the Lua standard library because PCRE is fairly large, by Lua standards.
By the way, for formatting Lua tables for debugging I like using "inspect". (It's not part of the standard library but oh well, that's the whole topic
of today's discussion).
Sure PCRE support would be big, but even posix-style BRE would be a very welcome improvement I think.
(As for formatting tables, presently most of my Lua code has been written for mpv which has a builtin utils.to_string(v) for this purpose. In the manpage, this is documented as "only needed because Lua is terrible." I think that's a bit too far, but the frustration this must have caused really comes across.)
I have to say, once I learned to appreciate the combo of Lua's builtin pattern matching (no not _that_ kind of pattern matching) and LPEG, I really loathe having to use cryptic regexp's in languages like JS.
Patterns are enough for most stuff, and when you want to get into more complex patterns, a PEG (LPEG in particular) is much more readable and expressive than a regex that would come out looking like a generated password.
A built-in function to convert a table to a string would be great. It's not hard to write one myself but tables are so core to the language and printing them is handy for debugging and exploration.
I agree with speeder in that Lua and C are probably two of my most favorite languages. I think developers come away with that feeling for the same ideological reasons.
Lua is also hands down the easiest programming language to embed. There's just no comparison. LuaJIT's C FFI also makes embedded work ludicrous.
I like lua, it's the language that really made me start to 'get' programming. It's great for lots of things, but it does have some weirdness I find makes some tasks a little more difficult. The lack of 'batteries' has never really been something that's bothered me with lua. A few other things though:
The starting arrays from one thing, while not that big of a deal, can be a bit annoying, especially if you're using lua and c together. You've just always kind of got to be aware of it.
Tables and metatables are great, until they're not.
Lack of true integers(at least when I used it) made at least one task I tried to use lua for unfeasible and I had to use a different language in the end.
In the end though, lua's still probably my favourite scripting language to write in.
Yeah, but adoption is slow. Nonetheless, looking forward to it. Hedgewars uses deterministic lockstep, and the various creative ways in which floating point is calculated really mess up games like this. 0AD and Spring discovered this in the past as well - so the result is scripters have to be very careful when using math, and Hedgewars had to expose its own bitops and integer division for lua scripting.
Yes, Lua 5.1 was a very good version. Lua 5.2 made some significant changes in how global variables work, which lead to a split between Lua and LuaJIT [1][2]. Lua 5.3, with true integer support [3] and some UTF-8 support made for a compelling reason to update. Lua 5.4 is out now with support for a more deterministic way to release resources.
I think LuaJIT being mostly stuck with Lua 5.1 is a cause for the lack up uptake on more modern versions of Lua.
[1] Mike Pall, creator of LuaJIT, disagreed with the direction that Lua 5.2 went and remained with Lua 5.1 semantics.
[2] I personally found Lua 5.2 a "meh" version and didn't bother upgrading.
[3] Including some functions to pack and unpack integers and floats into strings, in both big-endian and little-endian formats.
This was back in 5.1 and I haven't really played around with 5.3 at all. I did kind of remember reading true integers were coming to lua at some point, hence why in my post I wasn't sure if it was still the case.
This is really timely article for me. I just chose to use Lua in a brand new project (https://github.com/Hyperspace-Logistics/heart) and lot of the criticism so far has been “why Lua?”
Personally I think it’s very capable language. It’s such a comfortable scripting language that I think nearly anybody could pick it up and get up to speed pretty quickly. LuaJIT is also ridiculously powerful and so satisfyingly stable (Lua 5.1 for over a decade).
Heck Lua 5.1 even makes an excellent transpile target so you might not even need to use Lua to appreciate the software that runs Lua.
> "Everyone has different needs so the places where serious money is getting poured into using Lua don't really have much of an incentive to standardize -- it wouldn't give them any benefit."
I really don't think that's true. It _is_ true that a standard library doesn't cater to single developers' or companies specific, custom needs and performance tradeoffs. But that's only true for limited parts of the code. Most of an application's code is not the critical "secret sauce", and typically, we are well served with standard library facilities. We simply don't use the small part where we need something different.
It's like that for basically any high-level language, I believe; and standardization is desirable and appreciated. Are we really to believe that most big LUA users need their own regex library for LUA? Their own sqlite library? etc.
Lua is a bit weird and I think it's actually the strong point in favour of Lua (besides the obvious: nice performance and great portability). We need more variability to explore different ways to achieve our goals and to suit widest range of preferences. I'd love to see a big and strong standard library for the language to see it used for wider variety of tasks.
In my extremely limited experience with Lua, the only thing that I definitely didn't like was its weak-ish dynamic typing, so I'd been keeping my eye on tl[1] and wu-lan[2] which both transpile to Lua for a while.
Thing like JSON, make HTTP request all require external lib in Lua. It makes thing harder for first time user. I think at least JSON or HTTP client lib should be included?
One of my use case is use Lua as an OAuth proxy, run inside Nginx, or use Lua as a S3 Proxy(with sign signature etc) and dealing with XML/JSON/HTTP Request is hard in Lua.
When I installed an external lua rocks, for it to be embeded inside Nginx, I have to make sure lua lib path are sync between luarock/nginx.
I don't know how to solve that problem other than reading the document. But explains all of them to a new comer to Lua/Nginx is hard. It takes a lot of time until they can write code.
Interesting as I've just recently turned to learning Lua for use precisely as it is described as a "scripting language".
Out of several dozen alternatives (the other scripting languages from a list on Wikipedia), my analysis is that Lua offers a very compelling and attractive technical profile.
I haven't been using it long, but so far I haven't seen evidence otherwise. Prior to Lua I would have used Bash, or maybe Python in a pinch.
> "an official list of approved Lua libraries", which could be searched and that would provide information on the strengths and weaknesses of the library
Perhaps something to emulate could be https://djangopackages.org/ which has repeatedly helped me with "how do I do X" questions in the context of Django web projects.
I once wrote a system where we chose Lua as the scripting language specifically because of its lack of batteries.
When embedding a language in another system, you have to worry about the abstractions the standard library enforces upon the rest of your system if those abstractions are deep. Far better, for our purposes, to use a language with an absolute handful of primitive types and build abstractions atop it.
Lua was basically made as tool for making scripting environment for your app. It has minimal batteries because it's up to you to provide functions/API for your scripts.
I personally like lua because it's conceptually very simple. It has just eight basic types and that's all. Also it does not dictate you how to use it. It provides mechanisms, not policies.
Lua is a great language, but the fragmentation between versions makes it difficult to be adopted outside of niche embedded areas. On a side note, we maintain a Lua newsletter but haven't had time to update it. This article looks perfect for a new edition.
I've used Lua professionally and for hobby projects, and it's near the bottom of my list for languages I'd reach for in any context.
There's a significant mental lift for me to be productive in Lua, there are tons of weird gotchas, and I find it to be super verbose. Even basic stuff like parsing JSON I end up having to go rummage around for support for.
These days, I'll use javascript or python for my smaller needs, and I'd much rather have a JS runtime embedded than a Lua one for any game scripting I'm doing.
On the last advent-of-code I thought, that I should give Lua a try. But geez, on windows I really had a rough start.
First and foremost there is no easy guide how to even get started. Do you need MSYS2? TDM-GCC? Should I use WSL? Are there any precombiled binaries? Is there an editor?
Then by sheer luck I found the ZeroBrane Editor [1] and was quite excited. Simple installation, everything included, autocomplete and debugging! Awesome.
The first thing I had to do was trimming a string. Oh Boy! [2] I mean really.. As a beginner, this completely wrecked me. I have a task to do, why should I worry about which Trim implementation is best?
Switched to Nim (which I had not used before either) and never looked back.
If you are whipping up a command-line script because what you want is too complex to attempt in Bash, use Python. Lua is terrible for this.
If you are making an application from scratch using just the stand-alone interpreter, your scripts and a bunch of dependencies from the internets, use Python. People work really hard to make this semi-viable in Lua, but it is a path of frustration.
If you have your own C/C++ program and you want an easy path for configuring and composing features that are written in C/C++, deciding between Lua and Python depends on your goals.
Do you want MAXIMUM POWER for the scripter to whip together any crazy feature they might dream of? No concerns about footguns, hanging ropes or corner-painting? Memory and performance are secondary concerns to flexibility? Go use Python!
Do you want minimum power for the scripter so as to keep their creations constrained within a defined box? Is there a pre-defined role that the script will play? Are there definite restrictions on what should and should not be done in scripts? Are you going to be responsible in practice for debugging some monstrosities that the scripters build for themselves? Are performance and memory primary concerns above flexibility? Then Lua is well suited for embedding into your application.