- you basically always want a local but you have to ask for one, it's a bit noisy. 'strict mode' is easily applied to the global environment, and catches most outright errors here.
- there is an adequate amount of library and extension code, but less than you'd expect coming from Ruby or Python. The lack of a blessed object system sometimes means taking more effort to understand what other people's code does.
pros:
- variadic functions and multiple return values make for a truly dynamic language
- first class functions which are fast and work well: everything is a closure, a whole file is just an anonymous function called a chunk
- the table as a single compound data structure works very well, and metatables are a unique and excellent solution to extending behavior. Array portions are required to be compact (non-nil from 1 to #tab), which can be worked around on the few occasions when it's inappropriate.
- asymmetric coroutines.
- first class environments, which are just, yep, tables. this allows for a few really nice things.
- fast. LuaJIT is very fast. Both Lua runtimes fit in a typical L1 cache, and it uses a register VM, which is a good fit for real processors vs. stacks. No global interpreter lock, all C level Lua functions receive a Lua_state as the first argument and are fully reentrant.
- in general the emphasis on minimalism means the whole language "fits in head", and the tools provided are more than adequate to get jobs done.
- the LuaJIT FFI, which parses C declarations directly, is simply a pleasure to use, and is the only one of which I'm aware where you pay an absolutely minimal penalty to use it. There's just nothing like it. More languages need to have this.
miscellaneous:
Semicolon insertion is simply a non-issue, unlike JS it was implemented properly. I have well under one semicolon per file, less than one per project, even. It's very, very occasionally nice to write more than one statement per line; that's what the semicolon does.
> [...] and multiple return values make for a truly dynamic language
If you are using a word "dynamic" as "once-good-but-now-increasingly-considered-worse-and-worse", I agree. Lua is definitely too dynamic to be safely used.
Weeks ago I had to debug a Lua code looked like this:
If you can catch a problem, great! But most wouldn't be able to do so. And I used Lua for a prolonged time, to the extent that I have made a type checker which absolutely flags this case [1] and developed a very good list of intrinsic problems of Lua which obviously includes this one and still failed to notice the problem. Lua is a small language, but packed with lots of similar problems.
I tend to use lpeg for any complex string manipulation. gsub has bitten me once or twice by not thinking through whether something is a pattern nor not, sure.
In some sort of deploy scripts, converting a command "template" into the actual command by replacing a fixed string "<arguments>" into the escaped arguments (I know, this is not sufficient but also not the exact code, I've simplified it for the easier inspection). Now guess what's the problem without looking at the manual.
Also, don't say "use lpeg". Unless Lua supports a proper package system for every circumstance it's not a solution. Note that this deploy script runs in an embedded context, so no to luarocks and kins.
But, no: I meant that after the fiftieth time I had to modify every call site of a Python function because I realized I needed to return a tuple rather than a scalar sometimes, I came to really appreciate multiple return values.
Thanks! Quite a few things I didn't know in here, and on balance it does seem compelling.
Still can't quite understand why they would choose the 1-based indexing, it's just such an unforced error, unless the intention was literally just to fuck with people.
I suppose I could get over being fucked with, though.
cons:
- 1-based indexing
- you basically always want a local but you have to ask for one, it's a bit noisy. 'strict mode' is easily applied to the global environment, and catches most outright errors here.
- there is an adequate amount of library and extension code, but less than you'd expect coming from Ruby or Python. The lack of a blessed object system sometimes means taking more effort to understand what other people's code does.
pros:
- variadic functions and multiple return values make for a truly dynamic language
- first class functions which are fast and work well: everything is a closure, a whole file is just an anonymous function called a chunk
- the table as a single compound data structure works very well, and metatables are a unique and excellent solution to extending behavior. Array portions are required to be compact (non-nil from 1 to #tab), which can be worked around on the few occasions when it's inappropriate.
- asymmetric coroutines.
- first class environments, which are just, yep, tables. this allows for a few really nice things.
- fast. LuaJIT is very fast. Both Lua runtimes fit in a typical L1 cache, and it uses a register VM, which is a good fit for real processors vs. stacks. No global interpreter lock, all C level Lua functions receive a Lua_state as the first argument and are fully reentrant.
- in general the emphasis on minimalism means the whole language "fits in head", and the tools provided are more than adequate to get jobs done.
- the LuaJIT FFI, which parses C declarations directly, is simply a pleasure to use, and is the only one of which I'm aware where you pay an absolutely minimal penalty to use it. There's just nothing like it. More languages need to have this.
miscellaneous:
Semicolon insertion is simply a non-issue, unlike JS it was implemented properly. I have well under one semicolon per file, less than one per project, even. It's very, very occasionally nice to write more than one statement per line; that's what the semicolon does.
It's a nice language.