Part of the reason for stagnation was because you really need new language features -- i.e. yield/send, yield from, etc. JavaScript already had the necessary language features for its concurrency model.
async read(connect, readMessage, print) {
const sock = await connect('localhost', 7942),
msg = await readMessage(sock);
print(msg);
}Lua was quite pleasant to work with in this context!
The different syntax also prevents you from creating functions that can be reused by both sync and async code.
The big thing promises and other callback-based control flow libraries do is that they fix exception handling in async code (its a PITA to add error handlers in every callback when writing async code by hand). They also let you avoid some of the awkward "pyramid of doom" nesting but thats not really killer feature because you can also achieve that by using tons of named functions.
The required bits are in place... alternatively you can use co/koa which uses generators along with yeilding promises to act in a similar fashion.. it does work pretty well, and will only get better.
Don't despair the future is bright :)
And that's why Python supports `asyncio` (not to be confused with `asyncore` which is obsolete). So I prefer:
to this callback hell: And they're completely equivalent. Why would someone actually like the latter, except you're forced to use it because of the prevalence of JavaScript?`asyncio` is not only easier to use than the traditional "manual" state machines with classes, but also much faster than something like `Twisted`. In my crappy local benchmark[1], it easily beat `Twisted` in a considerable margin. That may be because of the flaws in my test code, but still their performance is on par. I see no points in relying on callback hell, at least in Python, except the lack of the libraries that support asyncio, which makes me a little bit sad.
[1] https://github.com/barosl/ws-bench