SAsametmax·Jul 15, 2018
Be careful with this. I'm not saying you should not do it, but consider you'll have to design it very carefully.
In python you can chose what event loop to hook to async/await, and hence we have gevent, qt, uvloop, twisted, asyncio, tornado, trio and curio as competing implementations.
They are very difficult to mix, and their ecosystems are mostly isolated, dividing the man power to add features, fix bugs, provide support, create libs or frameworks and write docs or tutorials.
Another problem is that you have (except for gevent which causes other problems by monkey patching the stdlib) to setup the event loop explicitly.
Those mechanisms are complicated, easy to get wrong, confuse beginners, make docs introduction long and annoying or misleading before getting to anything interesting.
E.G: to use asyncio, you are exposed to an event loop
Read the rest
, an event loop policy, awaitable, coroutines, coroutine functions, futures, tasks and task factories.
But there is worse... You can setup any event loop any way and time you want, and because the api is public, another lib can come and swap it. No lib to my knowledge provide any form of locking.
This leads to some weird situation where libs are considered so low level you end up writing wrappers on top of it (e.g: https://github.com/Tygs/ayo) just to be able to start using it sanely.
Now compare with JS.
I'm really not a fan of the language. However, even when you can't use async/await, using a promise is straightforward. You don't have to bother about creating the loop, starting it, stopping it, cleaning after it has stopped. You don't have to wonder if somebody is going to swap the loop. You don't have to get a reference to a loop to schedule anything. Actually you can mostly ignore the loop and just code the solution to your problem.
Now this makes JS dependent on one loop implementation for each runtime. Also you can't code any new async feature in JS, only use the existing ones. It's probably not what you want for a language like rust.
However, you should learn from the python ecosystem fragmentation and overly exposed low level API to avoid the same mistakes.
Somebody that just wants to use async/await should not have to learn how the implementation works in details, nor take so much precaution to avoid implementation lock in or break somebody else work.
And you really want a federated ecosystem. Having 7 incompatible websocket lib sucks.