5 ms·
I knew someone else had to be thinking about this! The thing is that Node.js has kind of solved this now The question is whether Lua's advantages over JS (mor
by gruseom 15y ago
I knew someone else had to be thinking about this!
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.
- chubot 15y agoYup. For semantics, I'm sure you can find some corner cases where closures behave differently, and the prototypal inheritance also probably differs in some significant ways. I haven't thought about it in awhile. 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.