5 ms·

I'm loving how everything is moving to JS :) Can someone explain why I might want to use Lua in a browser over JS? Does it have a fundamental feature that JS

I'm loving how everything is moving to JS :) Can someone explain why I might want to use Lua in a browser over JS? Does it have a fundamental feature that JS does not have? Cool name btw!

swah 13y ago
I hate how everything is moving to JS :) I wish somehow there were multiple languages targetting a common bytecode.. but that won't happen for some reason I can't understand because I stopped in the middle of the dragon book.
- chrisdevereux 13y ago
  I don't think the dragon book will help unless the new edition has a section on how to organise a standards committee for your new language.
- rayiner 13y ago
  http://www.jwz.org/doc/worse-is-better.html http://www.jwz.org/doc/worse-is-better.html
- rubiquity 13y ago
  Personally, I feel that the biggest slap in the face to developers in the last decade is that V8 uses native code instead of byte code. In 10-20 years I hope we look back on Google's decision to do that and hate them for it.
  - jlebrech 13y ago
    it compiles to an ast first
    - stcredzero 13y ago
      Years ago at Camp Smalltalk, Smalltalk VM implementers talked about compiling everything to ASTs instead of bytecode.
    - espadrine 13y ago
      I do understand why nobody would want to target Hydrogen directly, but here's a Hydrogen IR inspector tool: http://mrale.ph/irhydra/1/#ir http://mrale.ph/irhydra/1/#ir
  - CmonDev 13y ago
    "In 10-20 years" - let's hope ES6 is released before that.
  - herokusaki 13y ago
    Honest question: why is it a slap in the face to developers?
    - rubiquity 13y ago
      Because we could then have a virtual machine that we could send bytecode to, instead of having all of these languages that compile to JavaScript, which eventually gets compiled to native code by V8.
- ben0x539 13y ago
  I think the point of contention is that there isn't really such a thing as a completely language-neutral bytecode, so nobody can agree on whose language-specific-js-replacement vm to ship.
  - stormbrew 13y ago
    If JS ever gets finalizers we could probably consider the total feature set JS has at that point sufficient for the implementation of most other dynamic languages without resorting to writing a VM in js or using asm.js to embed a full C runtime using arraymaps for a heap. At that point we'd probably see some subset of JS devolve to a bytecode, I'll bet.
- Yorrrick 13y ago
  It's simple. "Bytecode" is just a kind if encoding. The only thing it does is make programs marginally smaller and marginally quicker to decode. It's not enough to justify enormous switching costs. Let's talk about what functionality this new thing should have. That's where the high-value opportunities are. But, it's also where there's no easy consensus.
  - stcredzero 13y ago
    Hence, there are high value opportunities in JS as a compilation target/runtime platform.
  - duaneb 13y ago
    You know what's a perfect, concise byte code? An ast-laden ASCII blob. What's the byte code for a byte array again? Oh there isn't one.... What's the byte code for a compare and swap? Shit....
rational_indian 13y ago
It has 1 based indices, oh joy!
- stcredzero 13y ago
  Yes, but you can code with 0 based indices just fine, when you need it. I know, because I've done it.
plorkyeran 13y ago
Coroutines, and Lua's metatables are more powerful than what can be done in ES5 (ES6 closes the gap a bit, and generators are equivalent to coroutines). Lua is pretty much JS done right, which actually makes it a poor choice for something like this IMO. A program written in Lua is not going to be fundamentally different from the same program written in JS, and the problems introduced by using this (worse debugging experience etc.) are very likely to outweigh the benefits of avoiding JS's warts.
- stcredzero 13y ago
  (worse debugging experience etc.) How do you know? Maybe try this first? Apparently, there is a in-browser debugger you can activate just by including two files. This is theoretically a first-class debugger that doesn't even need source maps. http://moonshinejs.org/how-to/debug-locally/ http://moonshinejs.org/how-to/debug-locally/ Were you assuming that Moonshine is a compiler targeting Javascript? It's actually a Lua bytecode VM.
- anonymoushn 13y ago
  Generators are equivalent to corourintes only as long as every single function you write is a generator and every single function call (to one of your own funcitons, anyway) is actually delegating to another generator. You can use a trampoline to make this less painful, but then you don't get to see your "real" call stack in the debugger...
- Tanner 13y ago
  From my cursory evaluation, the debugging support is actually better than vanilla Lua. The only point of friction I can see if that you have to "compile" something that is normally interpreted.
  - paulcuth 13y ago
    This is true. However the distiller can --watch a directory and do this step for you in the background. For more info: $ moonshine help distil

I'm loving how everything is moving to JS :) Can someone explain why I might want to use Lua in a browser over JS? Does it have a fundamental feature that JS does not have? Cool name btw!

swah 13y ago

I hate how everything is moving to JS :) I wish somehow there were multiple languages targetting a common bytecode.. but that won't happen for some reason I can't understand because I stopped in the middle of the dragon book.

chrisdevereux 13y ago
I don't think the dragon book will help unless the new edition has a section on how to organise a standards committee for your new language.
rayiner 13y ago
http://www.jwz.org/doc/worse-is-better.html http://www.jwz.org/doc/worse-is-better.html
rubiquity 13y ago
Personally, I feel that the biggest slap in the face to developers in the last decade is that V8 uses native code instead of byte code. In 10-20 years I hope we look back on Google's decision to do that and hate them for it.
- jlebrech 13y ago
  it compiles to an ast first
  - stcredzero 13y ago
    Years ago at Camp Smalltalk, Smalltalk VM implementers talked about compiling everything to ASTs instead of bytecode.
  - espadrine 13y ago
    I do understand why nobody would want to target Hydrogen directly, but here's a Hydrogen IR inspector tool: http://mrale.ph/irhydra/1/#ir http://mrale.ph/irhydra/1/#ir
- CmonDev 13y ago
  "In 10-20 years" - let's hope ES6 is released before that.
- herokusaki 13y ago
  Honest question: why is it a slap in the face to developers?
  - rubiquity 13y ago
    Because we could then have a virtual machine that we could send bytecode to, instead of having all of these languages that compile to JavaScript, which eventually gets compiled to native code by V8.
ben0x539 13y ago
I think the point of contention is that there isn't really such a thing as a completely language-neutral bytecode, so nobody can agree on whose language-specific-js-replacement vm to ship.
- stormbrew 13y ago
  If JS ever gets finalizers we could probably consider the total feature set JS has at that point sufficient for the implementation of most other dynamic languages without resorting to writing a VM in js or using asm.js to embed a full C runtime using arraymaps for a heap. At that point we'd probably see some subset of JS devolve to a bytecode, I'll bet.
Yorrrick 13y ago
It's simple. "Bytecode" is just a kind if encoding. The only thing it does is make programs marginally smaller and marginally quicker to decode. It's not enough to justify enormous switching costs. Let's talk about what functionality this new thing should have. That's where the high-value opportunities are. But, it's also where there's no easy consensus.
- stcredzero 13y ago
  Hence, there are high value opportunities in JS as a compilation target/runtime platform.
- duaneb 13y ago
  You know what's a perfect, concise byte code? An ast-laden ASCII blob. What's the byte code for a byte array again? Oh there isn't one.... What's the byte code for a compare and swap? Shit....

rational_indian 13y ago

It has 1 based indices, oh joy!

stcredzero 13y ago
Yes, but you can code with 0 based indices just fine, when you need it. I know, because I've done it.

plorkyeran 13y ago

Coroutines, and Lua's metatables are more powerful than what can be done in ES5 (ES6 closes the gap a bit, and generators are equivalent to coroutines). Lua is pretty much JS done right, which actually makes it a poor choice for something like this IMO. A program written in Lua is not going to be fundamentally different from the same program written in JS, and the problems introduced by using this (worse debugging experience etc.) are very likely to outweigh the benefits of avoiding JS's warts.

stcredzero 13y ago
(worse debugging experience etc.) How do you know? Maybe try this first? Apparently, there is a in-browser debugger you can activate just by including two files. This is theoretically a first-class debugger that doesn't even need source maps. http://moonshinejs.org/how-to/debug-locally/ http://moonshinejs.org/how-to/debug-locally/ Were you assuming that Moonshine is a compiler targeting Javascript? It's actually a Lua bytecode VM.
anonymoushn 13y ago
Generators are equivalent to corourintes only as long as every single function you write is a generator and every single function call (to one of your own funcitons, anyway) is actually delegating to another generator. You can use a trampoline to make this less painful, but then you don't get to see your "real" call stack in the debugger...
Tanner 13y ago
From my cursory evaluation, the debugging support is actually better than vanilla Lua. The only point of friction I can see if that you have to "compile" something that is normally interpreted.
- paulcuth 13y ago
  This is true. However the distiller can --watch a directory and do this step for you in the background. For more info: $ moonshine help distil