> May be one way to revive Lua would be to have an implementation in
> _javascript_ (I'm sure it will perform better and more safely than the
> current implementation in C/C++, and _javascript_ engines are now much
> easier to integrate and offer better integration with many more
> libraries, including with other languages like Python, Perl, SQL,
> PHP)...
Er, seriously? Compiled _javascript_ is faster than C? How is the current version of Lua not “safe”? It’s one of the most stable code bases I’ve ever encountered.
The performance claim might actually have some merit, actually. The current Lua interpreter is a very lean, efficient interpreter, to be sure, but it's only an interpreter. Modern _javascript_ implementations have sunk ridiculous amounts of effort into JIT compilation. A Lua-to-JS transpiler would almost certainly outperform Lua's C implementation at runtime, if the only metric you cared about was the speed of pure Lua code execution. An implementation of Lua in _javascript_ may or may not end up outperforming the C implementation depending on how it's done and how the JIT decides to approach it. (PROBABLY not, but I've seen some impressive stuff before -- it's possible that a sufficiently clever implementation might be able to pull it off.)
I can't speak to the safety claim. It doesn't seem to make a whole lot of sense. I can only assume it has something to do with VM sandboxing, but once you start putting in bindings to native code any safety promises from the VM become irrelevant.
On the other hand, I must strongly disagree with being easier to integrate. Lua is one of the best languages I've ever seen when it comes to embedding. That is, in fact, where Lua particularly shines -- it's very, very lightweight, with an API that's not too bad to work with once you get used to it. Embedding V8 isn't as nasty as it used to be but it's still not nearly as nice and it's way heavier.
/s/ Adam
