Lua is terribly impressive. Someone needs to make a transpiled language targeting Lua and JS. They're semantically close enough that this might not be too complex. If it worked well, it would be an interesting alternative to Node.js, since you could write the server-side for Lua coroutines and so on. Not to mention its performance.
However, the grammar rules are fairly convertible. I've converted a parser that normally targeted javascript, to target lua instead (it was for a project to convert lua code into json).
You could make it easy to take advantage of Lua-only features like metaprogramming by denoting them server-side only. You'd have to do that to get coroutine support anyway.
The idea seems so exciting and obvious that I wish I had time to do it. Lua doesn't seem to be used much for server apps, though. Why? Are there technical limitations that make it unsuitable, or is it just that it hasn't been exploited yet?
Another thing I'd like to know, given how embeddable Lua is, is whether one could embed it as a browser plugin and then get the power of Lua client-side as well. Obviously, one wouldn't demand this of users, but it would be a pretty sweet option to offer: "install this little plugin to make the program faster and more responsive".
One final thought. I wish Google had gone with Lua instead of making Dart. Lua is basically JS done right. Seems to me they could have built a compelling case around it.
The thing is that Node.js has kind of solved this now, as long as you can put up with JS. JS is ugly, but Lua is also not without its annoyances (1 indexing, and to me begin/end is a big pain over {}).
v8 probably doesn't perform as well as LuaJIT, but it's by far good enough for most purposes.
JS is ugly, but it's even uglier to have to worry about the transliteration to 2 different languages. 99% of it will work, but it won't be "write once run anywhere" -- we all know what a fallacy that is.
But since CoffeeScript became popular, I wonder how easy it would be to port a subset of CoffeeScript or a slight alteration of CoffeeScript to Lua (or even Python). I've seen MoonScript (http://moonscript.org/)
A third thing is that libraries would be totally different. You would have to bind the same libraries to JS and Lua to get any kind of portability. In the end I think that's not worth it for any project.
There's a node.js style API for Lua, but again it won't be "write once run anywhere".
https://github.com/luvit/luvit
A last motivation was the C API of Lua, which is nice and simple and portable. It seems way easier to work with that extending Node, which is tying your code to a particular JS implementation.
The thing is that Node.js has kind of solved this now
The question is whether Lua's advantages over JS (more powerful, faster, excellent FFI) can be exploited server-side to create significant value beyond Node.js. If the answer is no, the idea is pointless.
Lua is also not without its annoyances (1 indexing, and to me begin/end is a big pain over {}).
1-indexing is the sort of thing that could screw up cross-compilation. That's a worry. Begin/end - I agree with you, but don't have to deal with it because I write my JS in Lisp. Personally what I have in mind is a Lisp that compiles to JS and Lua.
it's even uglier to have to worry about the transliteration to 2 different languages.
Right. The idea lives or dies on how bad the semantic delta is between Lua and JS (in some subset of both languages chosen for compatibility). The impedance mismatch has to be really small to make it worthwhile. It's not obvious if that's the case.
But since CoffeeScript became popular
I don't see how the impedance mismatch argument is any different for CoffeeScript/Lua than it is for JS/Lua.
A third thing is that libraries would be totally different. You would have to bind the same libraries to JS and Lua to get any kind of portability. In the end I think that's not worth it for any project.
Projects that don't depend heavily on client-side JS libraries wouldn't suffer too much.
There's a node.js style API for Lua, but again it won't be "write once run anywhere".
I don't find it very interesting, since you can just use Node.js for that style. The goal here isn't to cross-compile to Lua and Node.js. It's to cross-compile to Lua on the server and JS in the browser.
A last motivation was the C API of Lua
Right, that's potentially a big deal. For example, you could run your server app in Lua embedded in Nginx. I know people have been working on this.
I'm not concerned too much about performance because I don't think Python is too slow 99% of the time, and node.js is faster than Python.
So personally I don't think there is a strong motivation anymore, but if anyone tackles it I'll try it out for sure :)
Another motivation I forgot to mention was sandboxing. Actually that was motivation for the same idea with Python <-> Lua. I have a ton of of Python code lying around. A lot of it can be extended by the user. I want to expose some of these things as network services, but it is hilariously insecure to accept Python code from users in any way. I also have a bunch of coworkers who already know Python. So it would be cool if I could somehow have a sandboxed Python interpreter (this has been talked about MANY times on pyhon-dev, etc.; not doable with CPython).
One way to get that is to try to compile Python to the Lua byte code (not portable across versions), or to Lua source code. I think the semantic delta is even higher, so it's probably not going to work very well. You would end up halfway to writing a Python interpreter in Lua (e.g. semantics of dictionaries)
PyPy has some sandboxing I hear but it's too heavyweight/early right now.
Lua is really nice. I want to use it, and has advantages over Python and JS, but I can't seem to justify it for any project. The network effects of tools/libraries in Python and JS always win out.