4 ms·

If you enjoyed this, you will probably also like the same author's "The Novelties of Lua 5.2"[1]. [1] http://www.inf.puc-rio.br/~roberto/talks/novelties-5.2.pd

If you enjoyed this, you will probably also like the same author's "The Novelties of Lua 5.2"[1]. [1] http://www.inf.puc-rio.br/~roberto/talks/novelties-5.2.pdf http://www.inf.puc-rio.br/~roberto/talks/novelties-5.2.pdf

gruseom 14y ago
I absolutely love how they are making such major changes as late as version 5.2. I also love that one of them is goto. 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.
- catch23 14y ago
  Lua does have lots of metaprogramming that js lacks, and adding into js could be tricky since you'd essentially have to rewrite existing js code into new code that allows this. 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).
  - gruseom 14y ago
    The easy way would be to make a language that compiles to the semantic intersection of Lua and JS; that is, don't expose things that you can't easily generate both Lua and JS for. Such a subset would cover approximately everything I for one want to do in JS anyway. 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.
    - chubot 14y ago
      I had this idea too -- I wanted to share code between command line clients, web clients and servers. Having a language that compiled to both Lua and JavaScript seemed eminently doable because their semantics are quite similar (and even the syntax is pretty similar). 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/ 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 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.
      - gruseom 14y 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.
- alexchamberlain 14y ago
  You can use Lua to generate content for Nginx.
  - gruseom 14y ago
    I read the web pages about that a while ago. Do you know if people are using it?
    - alexchamberlain 14y ago
      If you look at the mail lists, the devs are quite keen. I think some of them have an Alibaba background, so it's probably used there.

gruseom 14y ago

I absolutely love how they are making such major changes as late as version 5.2. I also love that one of them is goto. 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.

catch23 14y ago
Lua does have lots of metaprogramming that js lacks, and adding into js could be tricky since you'd essentially have to rewrite existing js code into new code that allows this. 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).
- gruseom 14y ago
  The easy way would be to make a language that compiles to the semantic intersection of Lua and JS; that is, don't expose things that you can't easily generate both Lua and JS for. Such a subset would cover approximately everything I for one want to do in JS anyway. 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.
  - chubot 14y ago
    I had this idea too -- I wanted to share code between command line clients, web clients and servers. Having a language that compiled to both Lua and JavaScript seemed eminently doable because their semantics are quite similar (and even the syntax is pretty similar). 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/ 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 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.
    - gruseom 14y 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.
alexchamberlain 14y ago
You can use Lua to generate content for Nginx.
- gruseom 14y ago
  I read the web pages about that a while ago. Do you know if people are using it?
  - alexchamberlain 14y ago
    If you look at the mail lists, the devs are quite keen. I think some of them have an Alibaba background, so it's probably used there.