News for hackers. Stuff that matters.

A comment on Moonshine – A lightweight Lua VM for the browser.

Re:Moonshine – A lightweight Lua VM for the browser by binocarlos on Tuesday April 01, 2014 @08:56AM (#7507681)
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!

[ Parent | on HN ]
Re:Moonshine – A lightweight Lua VM for the browser by plorkyeran on Tuesday April 01, 2014 @10:23AM (#7508363)
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.

[ Parent | on HN ]
Re:Moonshine – A lightweight Lua VM for the browser by stcredzero on Tuesday April 01, 2014 @12:39PM (#7509570)
(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/

Were you assuming that Moonshine is a compiler targeting Javascript? It's actually a Lua bytecode VM.

[ Parent | on HN ]
Re:Moonshine – A lightweight Lua VM for the browser by Tanner on Tuesday April 01, 2014 @01:59PM (#7510300)
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.
[ Parent | on HN ]
Re:Moonshine – A lightweight Lua VM for the browser by paulcuth on Wednesday April 02, 2014 @09:30AM (#7515345)
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

[ Parent | on HN ]
Re:Moonshine – A lightweight Lua VM for the browser by anonymoushn on Tuesday April 01, 2014 @12:53PM (#7509696)
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...
[ Parent | on HN ]
Re:Moonshine – A lightweight Lua VM for the browser by swah on Tuesday April 01, 2014 @08:58AM (#7507693)
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.
[ Parent | on HN ]
Re:Moonshine – A lightweight Lua VM for the browser by Yorrrick on Tuesday April 01, 2014 @10:26AM (#7508386)
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.
[ Parent | on HN ]
Re:Moonshine – A lightweight Lua VM for the browser by stcredzero on Tuesday April 01, 2014 @10:31AM (#7508423)
Hence, there are high value opportunities in JS as a compilation target/runtime platform.
[ Parent | on HN ]
Re:Moonshine – A lightweight Lua VM for the browser by duaneb on Tuesday April 01, 2014 @06:12PM (#7512108)
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....
[ Parent | on HN ]
Re:Moonshine – A lightweight Lua VM for the browser by rubiquity on Tuesday April 01, 2014 @09:20AM (#7507874)
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.
[ Parent | on HN ]
Re:Moonshine – A lightweight Lua VM for the browser by CmonDev on Tuesday April 01, 2014 @01:01PM (#7509773)
"In 10-20 years" - let's hope ES6 is released before that.
[ Parent | on HN ]
Re:Moonshine – A lightweight Lua VM for the browser by herokusaki on Tuesday April 01, 2014 @07:40PM (#7512565)
Honest question: why is it a slap in the face to developers?
[ Parent | on HN ]
Re:Moonshine – A lightweight Lua VM for the browser by rubiquity on Sunday April 06, 2014 @11:52AM (#7541330)
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.
[ Parent | on HN ]
Re:Moonshine – A lightweight Lua VM for the browser by jlebrech on Tuesday April 01, 2014 @09:25AM (#7507911)
it compiles to an ast first
[ Parent | on HN ]
Re:Moonshine – A lightweight Lua VM for the browser by stcredzero on Tuesday April 01, 2014 @10:34AM (#7508452)
Years ago at Camp Smalltalk, Smalltalk VM implementers talked about compiling everything to ASTs instead of bytecode.
[ Parent | on HN ]
Re:Moonshine – A lightweight Lua VM for the browser by espadrine on Tuesday April 01, 2014 @11:22AM (#7508919)
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
[ Parent | on HN ]
Re:Moonshine – A lightweight Lua VM for the browser by ben0x539 on Tuesday April 01, 2014 @09:30AM (#7507960)
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.
[ Parent | on HN ]
Re:Moonshine – A lightweight Lua VM for the browser by stormbrew on Tuesday April 01, 2014 @03:12PM (#7510918)
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.

[ Parent | on HN ]
Re:Moonshine – A lightweight Lua VM for the browser by rayiner on Tuesday April 01, 2014 @09:14AM (#7507820)
http://www.jwz.org/doc/worse-is-better.html
[ Parent | on HN ]
Re:Moonshine – A lightweight Lua VM for the browser by chrisdevereux on Tuesday April 01, 2014 @09:08AM (#7507762)
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.
[ Parent | on HN ]
Re:Moonshine – A lightweight Lua VM for the browser by rational_indian on Tuesday April 01, 2014 @09:58AM (#7508189)
It has 1 based indices, oh joy!
[ Parent | on HN ]
Re:Moonshine – A lightweight Lua VM for the browser by stcredzero on Tuesday April 01, 2014 @12:40PM (#7509577)
Yes, but you can code with 0 based indices just fine, when you need it. I know, because I've done it.
[ Parent | on HN ]