Lua has tail call optimization and js doesn't. For me, this is a dealbreaker for js.
Lua also has operational advantages compared to javascript. You can build it from source in at most a few seconds and run it anywhere that has a c compiler. The startup time is negligible even compared to a compiled c program so you can run entire scripts that do very useful things faster than most js engines can print hello world. There is also the benefit that in spite of what this article discusses, it is possible for most problems to write a lua solution that works for all lua >= 5.1. This is wonderful because it means if I stick to the standard library, the bitrot is essentially zero.
Calling into c is very straightforward in Lua, especially with luajit, which makes it superior to js as a scripting language (the node ffi api is quite painful in my experience and ffi runs against the js execution model).
Lua also essentially got lexical scoping of local variables correct from the beginning while js blessed us with the nightmare of var.
Of course Lua is far from perfect, but while there are some similarities, the differences are quite significant and meaningful.
> Lua also essentially got lexical scoping of local variables correct from the beginning while js blessed us with the nightmare of var.
That was not my experience when I was working with lua. Did anything change since? Asked google. Answered :
> In Lua, if a variable is assigned a value inside a function without being explicitly declared with the local keyword, it will automatically become a global variable. This is because, by default, all variables in Lua are global unless explicitly specified as local.
Yeah, this puzzled me too. I'm assuming they're referring to the semantics of "var" in JS vs "local" in Lua, with the latter resembling "let" in JS, which doesn't have broken scoping.
> Calling into c is very straightforward in Lua, especially with luajit, which makes it superior to js as a scripting language (the node ffi api is quite painful in my experience and ffi runs against the js execution model).
As a scripting language for browsers this is an antifeature, and the fact Lua comes by default with a bunch of features that allow loading arbitrary binary code in the process makes it pretty annoying to properly use it as a sandboxed scripting language.
You're conflating a few things here. V8 and Spidermonkey aren't the only interpreters out there. There are a number of them explicitly designed to be small, easy to compile and to embed, such MuJS, Fabrice Bellard's QuickJS, and more still. I can't speak to their FFI interfaces, but you can't judge JS's ability to call C functions based off that of Node/V8. I'm not sure how FFI runs against its execution model given JS is generally used as an embedded language, necessitating foreign function calls.
If I remember correctly, TCO is now part of the ECMAScript standard. Safari has implemented it. The issue is that others engines have not because they are concerned about stack unwinding and stacktraces.
Lua also has operational advantages compared to javascript. You can build it from source in at most a few seconds and run it anywhere that has a c compiler. The startup time is negligible even compared to a compiled c program so you can run entire scripts that do very useful things faster than most js engines can print hello world. There is also the benefit that in spite of what this article discusses, it is possible for most problems to write a lua solution that works for all lua >= 5.1. This is wonderful because it means if I stick to the standard library, the bitrot is essentially zero.
Calling into c is very straightforward in Lua, especially with luajit, which makes it superior to js as a scripting language (the node ffi api is quite painful in my experience and ffi runs against the js execution model).
Lua also essentially got lexical scoping of local variables correct from the beginning while js blessed us with the nightmare of var.
Of course Lua is far from perfect, but while there are some similarities, the differences are quite significant and meaningful.