Hacker News Reader

Comment by binocarlos | Hacker News Reader

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!

View on HN

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.

(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.

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...

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.

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 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.

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.

http://www.jwz.org/doc/worse-is-better.html

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.

it compiles to an ast first

Years ago at Camp Smalltalk, Smalltalk VM implementers talked about compiling everything to ASTs instead of bytecode.

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

"In 10-20 years" - let's hope ES6 is released before that.

Honest question: why is it a slap in the face to developers?

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.

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.

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.

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.

Hence, there are high value opportunities in JS as a compilation target/runtime platform.

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....

It has 1 based indices, oh joy!

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

Reply on news.ycombinator.com