Moonshine – A lightweight Lua VM for the browser | Hacker News Reader

Moonshine – A lightweight Lua VM for the browser

moonshinejs.org

106 pointskeyle70 comments

This is great to see! It's important to note that this isn't just yet another "X compiled to Y using Z", but a VM written from scratch natively in Javascript.

The result is a much smaller size, it's more understandable, hackable, extensible - all things that Lua's standard C implementation is great for. It's likely also easier to optimise this way.

I began on a similar project some years back, but as many spare-time projects go, never finished it: http://code.matthewwild.co.uk/ljs

Interesting, any useful resources you recommend for those interested in learning how to write a VM in Javascript as a fun side project?

Don't write it in JS :)

No but seriously, if you want to write a VM in Javascript, I would suggest learning how to write a VM in a language more suited to writing a VM in. Maybe C or C++ then writing one in Javascript.

Do what you want. The nice thing about writing a managed language with GC in a managed language with GC, is that you don't have to write the GC. (Or the JIT, if you do it right.)

It's not really a VM then though, just a compiler.

EDIT: Maybe also a runtime.

Another good one - for those of us who love Lua (I Do!) is the MOAIFiddle editor:

http://getmoai.com/forums/moaifiddle-an-online-moai-editor-a...

(Edit: some direct links to already-working examples: http://moaifiddle.com/Q09BJWGMW6 and http://moaifiddle.com/262FBR1ZR8 and http://moaifiddle.com/262FBR1ZR8/2)

This is a full-blown (web-based) development environment for the MOAI Game toolkit, which just happens to be able to deploy to not only Android, iOS, Windows, Linux, OSX hosts .. but also - as demonstrated - to html5+js hosts.

So, if you've ever wanted to check out MOAI but have been put off by the need to build your own host for the OS of your choice, you can just use moaifiddle to get your project done, see the results directly in-browser, and prepare your app before even having to download the MOAI SDK. Sweet!

(More details about the cross-platform game toolkit, MOAI, are available here: http://getmoai.com/)

I love Lua too but I've tried to get into Moai several times and I just can't seem to stomach it. Maybe I let Corona spoil me.

The documentation is especially off-putting: http://getmoai.com/docs/

I've been working with MOAI for 3 years now, so I guess I'm quite biased - but I find it awesome.

Yes, the Docs - well these are generated docs, courtesy of doxygen. You really need to start at the wiki, and then work your way through all the samples in $MOAI_ROOT/samples/

http://getmoai.com/wiki/index.php?title=Main_Page

And of course the tutorials and other refs from the github:

https://github.com/moai/moai-dev/

MOAI does take some patience - but on the other side of that effort, is a fantastic framework that makes game development easy and fun. There's something just so elegant about it!

Moai is just... terrible.

I work with Lua-based engines on my startup, and right now the "winner" is Gideros.

Corona is also good (But has several issues that made me use Gideros for the current project, but all currently done projects were made with Corona).

Corona is going for HTML5, I hope Gideros can do something like that soon too.

MOAI already renders to HTML5. I don't know what you find terrible about it.. but am interested, so feel free to engage me in conversation. FYI, I've been using MOAI for 3 years so I'm not really feeling any negative reactions towards it as a framework - its really done a lot for me as a developer.

Mostly: Setting it up was a pain, developers clearly have no intention of really supporting it (they made explicit that their focus is their cloud project and their gamedev projects and that moai SDK is a sort of sideproject), the forum when I was trying to setup Moai was dead, community was overall weak, documentation was wrong and outdated...

I don't doubt Moai technical capabilities, I was very impressed by it, also the fact that it is FOSS is really cool, but the barrier to start using it was too big and insane.

Never experienced any of that as a serious problem, but I'm a 'compile from source' guy anyway - but yeah, the devs are of course using MOAI to make their own products (Games) and yeah - there are a lot of forks of MOAI alas, but in the last 6 months the Forum community has really risen to the challenge of self-organizing around all these forks, and this is reflected in the current release that was made by the community. So that has definitely improved. Docs: no longer outdated. Community: very strong - See moaiFiddle, this was born from the community after all.

I honestly think if you took a new look, you'd see the issues you described are not really show-stoppers/blocking any more. A lot of us in the MOAI community are busy using the thing to do actual releases ..

Maybe, I will take a look when the next cycle of choosing tech comes.

Right now I am in middle of making a point and click adventure with Gideros (obviously, Moai being used for Broken Age was one of the reasons why I looked into it in first place, I assumed that if Tim Schafer found it good for that, maybe for us it would be too).

After I finish it and use the engine (I am making a engine to be re-used for several episodes) for a couple games, maybe who knows what we will decide.

Well, great, I'd love to know your product when its released, let me know if you don't mind! ;)

Apropros MOAI in the future, just let your game start with Lua tables. Doesn't matter what the game is describing, but just .. do it with nice tables[].

Then, attach MOAIProp. :)

How does MOAI compare to LÖVE in terms of "batteries", codebase maturity and libraries written by the community ?

Maturity? Not as mature. Libraries written by the community - surprisingly there are a lot of little/efficient frameworks for MOAI already, like moaigui, Hanappe, and Flower. These are all user-contributed extensions that make working with MOAI even more joyous...

But yeah, you'll have to suit up for the task of producing a working MOAI host from sources .. this isn't done for you, it is after all free software and there's nobody to buy a license from ..

It would be nice to see other languages available as real languages, not compiled down to Javascript. I love me some javascript, but it would be nice to work in Python, in the browser.

It would be nice to see Lua embedded as an option within browsers, since it's such a small language and already designed to be embedded.

Lua is indeed, embeddable anywhere. Its such an elegant little VM, and you can just put it wherever you want. It is some sort of mad invasive engine .. you use it once, and from that point on you pretty much can't see anywhere else you wouldn't just use it, of course .. if you had to, or wanted to, and .. the more you use the Lua VM stack, the more you just want to keep doing things that way. It is neat.

There's http://www.skulpt.org/for Python in the browser.

You happened to append for to the url. As a convenience:

http://www.skulpt.org

That stuff uses JS. It would be nice to see a Python runtime in-browser with no JS involved whatsoever.

How do you envision this happening? Either the runtime would have to be written in JS or you'd have to get all the browser implementers to adopt your virtual machine — which, I mean, why would they?

"why would they" - and that is the saddest part. We are locked-in now.

I agree and used to agree very enthusiastically, but now I kind of understand the browser makers' position. Like, I don't love having my favorite runtimes locked out, but I also don't think having 15 virtual machines bundled with every browser would be a great outcome either. We've already seen how in-browser VMs turn out when they're not adequately maintained with Flash and Java, and it isn't pretty and it leads to people's money getting stolen. So I can't really blame the browser makers for not wanting to go down that road.

What we have now isn't the very best thing I can imagine, but I think it's an OK compromise. We have a set of runtimes that implement a fairly consistent Turing-complete set of instructions, so we can implement just about anything we want and express it almost any way we want. And in the end, I think that's the most important thing.

That would be an actual true Open Web. It's not going to happen.

Personally, I'd like to see a Scheme or ML dialect, but I'm not one to exclude good languages: I'd love to see some way to portably, reliably, and safely extend all browsers to support new language VMs - including languages like Dart, Python, Ruby, Lisp, etc. - without resorting to huge blobs of JavaScript that half-heartedly implement a half-useful language.

Things like ASM.js are interesting, but not really helpful, in my mind, as it just adds another unnecessary layer of overhead just to be able to implement something interesting in a language suited to it. I just wish browser vendors saw this the way I do.

What is the difference between a "real language" and "compiled down to JavaScript"? Like, every language is either interpreted or compiles down to something else. I'm not clear on what the real distinction is here. Are ClojureScript, Dart and Scala not real languages since they compile to JavaScript?

"Real" is probably the wrong term, chosen too quickly. Byte-code compatible is probably a better descriptor.

A presentation given at the London Lua Group about it's development: https://skillsmatter.com/skillscasts/3820-developing-a-lua-v...

...I know it's the fashion to write compile-to-js languages and js-VMs for other languages, but I really have to ask: WHY? I mean, Lua is a dynamic language with first class functions just like Javascript is, no big difference here.

I understand clojurescript, parenscript and haskell to js compilers, because these languages are really different from javascript, so they offer you a very different way of working and different tradeoffs (Clojure, CL, Haskell offer you the ability to choose a programming style that is just not possible in Javascript). Maybe even Opal or Amber - rubyan/smalltalkian oop semantics really are very different from Javascript's and you end up using very different design patterns. And I understand the wish to have static typing for large projects/teams, ergo TypeScript or Dart.

But I really don't understant why would anyone go through such pain (by pain I mean not writing the transcompiler/vm, this is the fun part, I know, but debugging it, maintaining it and debugging the code you use it on), to use a language so similar to Javascript, like Lua or Python, instead of using just plain Javascript and making some minor effort to 'use strict', avoid some dark corners and get used to living with a little less syntactic sugar?

WHY? I mean, Lua is a dynamic language with first class functions just like Javascript is, no big difference here.

You can use objects as keys in Lua. This makes a lot of code in Lua a pain to port to JavaScript. I have Lua code I would like to port to JavaScript that this applies to.

Got some sample code or a link to it? I really like figuring out ways to express existing code in a different style/pattern/language :)

Map¹ might've been an option, excepting no support in Safari and IE < 11. Although I dunno about the performance hit, if any.

¹ https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Refactor once: the object key. To a function returning the value of the object. Refactor a second time: function all the object things.

Whats not to like?

For the people that wrote Moonshine, it was the ability to use the same language across all platforms[1]. They already have a lot of Lua code on other platforms that was unable to run on the web (without using Flash, which also has a Lua VM available for it).

Lua is very portable, I wouldn't choose Javascript to replace it for multi-platform game development. However Javascript has a monopoly on the web. I don't see why this ought to be.

[1]: Source: https://skillsmatter.com/skillscasts/3820-developing-a-lua-v...

Because they were already using Lua as a cross-platform killer language, and wanted to just be able to share game-content with a slick, slimy, javascript layer?

This would be even more amazing if there was no dependency on `luac` to compile to Lua bytecode. I'm developing a web application with user-scriptable features, and I'd love to use Lua (to provide a better user experience for my non-webdev audience), but the dependency on a server-side compilation step is a problem for my use-cases.

There is a Moonshine extension[1] that uses Yueliang[2] to compile offline in the browser, but it's quite slow. I'm hoping to speed it up a bit in the near future, with the futures I'm working on now.

[1] https://github.com/gamesys/moonshine/tree/master/extensions/... [2] http://yueliang.luaforge.net/

Use luac locally to compile the bytecode, then include it in your deployment to the server somewhere?

The app front-end has user-scriptable features - I should have been more specific. My app has no back-end, and it is unacceptable to set up a back-end for the sole purpose of running luac on user scripts.

Has support for coroutines -- awesome!

[citation needed]

The examples don't support deep linking, so here's how you get to the example:

Try It -> Examples -> Coroutines

Ah. Thank you :)

I work with moonshine, if you have any questions I would be happy to answer them.

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!

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.

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

So weird to see this here

Reply on news.ycombinator.com