> It turns out that the entire compiled Lua VM fits in 200K when gzipped. That's too much for some use cases, but certainly acceptable for others (especially with proper caching).
Tell that to someone on a mobile device with poor connectivity.
> In particular, remember that the Lua VM is often significantly faster than other dynamic languages like Python and Ruby. These languages are useful in many cases even if they are not super-fast.
Something people often overlook is that performance is highly dependent on where the code runs. Ruby is fine for server-side programs because you can always go fast by throwing more hardware at it.
Languages that run on end-user machines don't have that luxury. This is why the playing field for client-side programming languages is much more constrained and why C++ is still hugely popular there. It's also why so much work has gone into optimizing JavaScript.
Being half as fast as JS could be tolerable for some apps, but that means your app will likely be slow and stuttery in some cases. When it is, there's little you can do about it. Is Lua that much of an improvement over JS to justify that?
> There are however some tricky issues, for example we can't do cross-VM cycle collection - if a Lua object and a JavaScript object are both not referred to by anything, but do refer to each other, then to be able to free them we would need to be able to traverse the entire heap on both sides, and basically do our own garbage collection in place of the browser's - for normal JavaScript objects, not just a new type of objects like Lua ones.
This is a huge deal. It basically means if you use this, your app is very likely to leak memory unless you are very careful. The difficulty of being appropriately careful is exactly why we moved to GC languages in the first place.
WebKit (now Blink on the Google side) actually has a similar problem already: WebKit manages memory for the DOM separately from V8's garbage collector. This adds a bunch of complexity to the browser to deal with those cycles and has, I think, a significant performance cost.
It's enough of an issue that the Chrome team is starting a new project ("oilpan") to provide a unified GC shared by both V8 and the DOM.
Don't get me wrong, I think this is a very cool hack. But I don't think it says much about the viability for using something like this for real apps, at least not yet.
> Is Lua that much of an improvement over JS to justify that?
This depends on the project, of course. For existing software that's already written in Lua and now needs to run inside a browser, running the Lua VM in JS may be the best way to go. However, I've decided that for new code, Lua doesn't have enough advantages over JS to justify the problems with running a VM in a VM.
Here are the things that I consider significant advantages of Lua over JS, and my thoughts on each.
1. Coroutines: JS is getting a form of these via generators, though I don't know how soon that feature will become ubiquitous. In the meantime, a compiler can turn code that uses coroutines into continuation-passing style.
2. Weak references: It's unfortunate that JS doesn't have these. But as the OP pointed out, running a VM within a VM introduces other memory management problems, since the guest VM has its own GC. To avoid those issues, I can live without weak references in the language.
3. Metamethods: The most well-known metamethods are for overriding table operations, so one can implement properties, proxies, or other dynamic behavior. I've sometimes found these useful on previous Lua projects, but for new code, I can do without them in order to avoid the problems of running a VM in a VM.
4. Non-string keys for tables/objects: There are ways around this. For example, instead of using another object as a key, one can assign a unique ID to the object, then use that as the key.
WeakMaps don't quite give you everything that weak references do in other languages. Sometimes weak refs can be used to check if the object referred to has gone away (the weak ref becomes null in that case), that is not possible with WeakMaps. You also cannot create a list of weak references and iterate over them with a WeakMap.
There has been some discussion about adding more powerful weak refs to JavaScript, but I'm not sure where that discussion stands.
I wrote a parenthetical about weak references. I wonder why I deleted it. In short: weakrefs are unlikely to appear any time soon in ES, as they open up all kinds of fun around cross-origin objects (being able to detect their approximate life-time, and that's a fairly major side-channel attack) in some lovely edge-cases.
If you have any more details about this, or even if you don't, please post to es-discuss about it. Currently there is broad consensus on TC39 to add weak references in JS in the future.
Tell that to someone on a mobile device with poor connectivity.
> In particular, remember that the Lua VM is often significantly faster than other dynamic languages like Python and Ruby. These languages are useful in many cases even if they are not super-fast.
Something people often overlook is that performance is highly dependent on where the code runs. Ruby is fine for server-side programs because you can always go fast by throwing more hardware at it.
Languages that run on end-user machines don't have that luxury. This is why the playing field for client-side programming languages is much more constrained and why C++ is still hugely popular there. It's also why so much work has gone into optimizing JavaScript.
Being half as fast as JS could be tolerable for some apps, but that means your app will likely be slow and stuttery in some cases. When it is, there's little you can do about it. Is Lua that much of an improvement over JS to justify that?
> There are however some tricky issues, for example we can't do cross-VM cycle collection - if a Lua object and a JavaScript object are both not referred to by anything, but do refer to each other, then to be able to free them we would need to be able to traverse the entire heap on both sides, and basically do our own garbage collection in place of the browser's - for normal JavaScript objects, not just a new type of objects like Lua ones.
This is a huge deal. It basically means if you use this, your app is very likely to leak memory unless you are very careful. The difficulty of being appropriately careful is exactly why we moved to GC languages in the first place.
WebKit (now Blink on the Google side) actually has a similar problem already: WebKit manages memory for the DOM separately from V8's garbage collector. This adds a bunch of complexity to the browser to deal with those cycles and has, I think, a significant performance cost.
It's enough of an issue that the Chrome team is starting a new project ("oilpan") to provide a unified GC shared by both V8 and the DOM.
Don't get me wrong, I think this is a very cool hack. But I don't think it says much about the viability for using something like this for real apps, at least not yet.