Re: Comparison of numbers of 3rd party libraries

[William Ahern <william@...>]

On Wed, May 13, 2015 at 09:31:18AM +0800, zejian ju wrote:
> Yes, there's no common application platform for lua, as node.js for
> javascript.
> 
> Openresty provides a web server platform for lua based on nginx, but
> there's no
> suitable package manager for it.
> 
> Comparing to js, I like lua because of lexical scoping, true coroutine,
> simple and
> consistent design, and without the ugly and strange parts of js. So I hope
> lua can
> be used pervasively.
> 
> But js seems catching up, let scoping/module/generator/async function will
> appear in the coming ES6.
> 

ES6 generators are a far cry from Lua's coroutines:

1) ES6 generators require a special function definition.

2) Lua's coroutines are symmetric--yield can return values provided by
resume.

3) ES6 yield can only be used in the generator function, whereas you can
yield from any function in the Lua coroutine call stack.

Javascript will never have Lua's coroutines because it would require huge
refactoring of the existing vendor VMs. Instead, Javascript chose
callback-based futures, and then tacked on generators as a band-aid to help
with the mess of callbacks. But generators will never be as elegant or as
useful as coroutines.

Furthermore, Lua's coroutine implementation is unique in real-world
languages in that it's stackless--it doesn't rely on the C stack to
implement coroutines, even when using the C API. (Stackless Python is only
stackless for Python code.) That has useful performance, memory, and
debugging characteristics. On some older platforms (notably the old
LinuxThreads implementation) you can't mix POSIX threads with fibers (the
Windows term for application-created C stacks), and in the future this
limitation may return in the form of security measures on more popular
platforms.