It's got an awesome C API. It's fast, lightweight, and embeddable. It's more performant than Python. It's a staple in video game scripting.
It's got an awesome C API. It's fast, lightweight, and embeddable. It's more performant than Python. It's a staple in video game scripting.
Semantically, Lua is almost identical to the core of JavaScript. Metatables are a genius alternative to prototype chains.
Lua's syntax is beautifully simple and unambiguous, but at the cost of being moderately inconvenient in 2025 unfortunately. It could benefit from an ESNext-style renewal.
I get why they made the C API that way, but in practice it's very easy to get wrong.
I'm not sure how fast vanilla Lua is today compared to similar languages. I think LuaJIT (and Luau?) are most often used when performance is needed.
yuescript, from the dora-ssr game engine dev, is essentially moonscript-2.0
And of course, if you want to treat lua as the scheme-like it really is (deep down), then ... fennel.
Lots of choices. They all compile to straightforward lua, are very easy to incorporate (you can even compile at runtime, if you wish), and all employ full lua semantics, meaning zero runtime overhead
EDIT: and the curse of not reading fully ahead strikes again (doh!). Someone else has made the same points below ...
Like another commenter said, using . instead of : is maybe the most common mistake, too easy to make. And Lua offers no help preventing or checking it.
TypeScript is a great language. So is Lua. So is C.
When used carefully to avoid their warts. Learning how to do that for any language takes time and practice though.
Yea, and then there's javascript (or typescript if you prefer), the C++ of scripting languages. It's sometimes difficult to see any value through the warts. (Unless you're paid to, of course.)
But, equivalently, of course I'm going to criticize a hammer if it's literally covered in warts making it difficult to grasp without slipping. (or, if the gun I'm trying to use keeps firing bullets into my foot when I'm aiming down range.)
- tables being used for both objects and arrays can create a lot of confusion, especially when you have some integer keys, but not all, and especially when they are not consecutive or one of them is 0 - indexes start at 1 - assigning nil deinitializes variables/entries instead of assigning the value `nil` (this becomes especially bad if you mistakingly try to use nil as a value in an array/table) - nil and false are falsy, but not 0, which instead is truthy
Many of the corners of C understanding come with inherently abstruse backgrounds: say, accessing fenced memory with an aliased value in-scope, or in getting the particulars of expected memory-layout right for a given ABI. None of this actually impacts most daily development.
Hell, the impact of using zero-terminated strings is far greater of an issue than poor-specification of the language is. You have to deal with this problem; POSIX decided to bake it in to its core. Pointer mismanagement is a generally difficult problem, but C decided to actively cook-in hard-to-manage-strings.
local print = print
("hello"):format()
local foo = func
("args to func"):itreturnedatable("!") local print = print("hello"):format()
local foo = func("args to func"):itreturnedatable("!")
And I'm sure they can guess that that does.I don't think that's true. It's a very embedded language. Its use in video games and video game modding alone would outnumber the number of people directly writing assembly to achieve things.