4 ms·

Why does it have to be either one? Why not the possibility of choosing the implementation you want to solve the problem? A language where you could easily run w

by he0001 8y ago

Why does it have to be either one? Why not the possibility of choosing the implementation you want to solve the problem? A language where you could easily run whatever you want would have my vote. Not having it shoved down my throat (I’m looking at you JS). While it’s possible to build most of it yourself you should have the possibility to choose.

sametmax 8y ago
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, 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 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.
- timClicks 8y ago
  Concur. Although perhaps the situation in Python could have been mitigated somewhat if a protocol was defined early that implementations could have adopted? Context managers, iterators and decorators all work nicely together, even across language boundaries via the extensions API.
  - sametmax 8y ago
    > Although perhaps the situation in Python could have been mitigated somewhat if a protocol was defined early that implementations could have adopted? Yes. That's one thing the rust community has to get right. async/await was supposed to be that, but it's only a protocol to define what blocks/doesn't and when you allow context switching. An event loop also has the notion of scheduling, getting a reference to what is scheduled, request the result or error on said scheduled thing, or cancel it. And even loop must bridge different implementations of concurrency (e.g: asyncio.run_in_executor). An event loop also has a life cycle, which includes at the very least a setup and a tear down. An event loop must integrates in an environment, like what do you do when you have several loops, or if you run one loop per threads ? So you need to define a general behavior for all that. Then let anyone write the implementation the way they want.
    - steveklabnik 8y ago
      That’s all of this: https://doc.rust-lang.org/nightly/core/task/ https://doc.rust-lang.org/nightly/core/task/
      - sametmax 8y ago
        That's an API. Like asyncio in Python is an API. If you make the event loop swapable without making this API mandatory however, it's never going to be a protocol.
        steveklabnik 8y ago
        The api is mandatory; it’s how async/await works.

by he0001 8y ago

sametmax 8y ago

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, 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 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.

timClicks 8y ago
Concur. Although perhaps the situation in Python could have been mitigated somewhat if a protocol was defined early that implementations could have adopted? Context managers, iterators and decorators all work nicely together, even across language boundaries via the extensions API.
- sametmax 8y ago
  > Although perhaps the situation in Python could have been mitigated somewhat if a protocol was defined early that implementations could have adopted? Yes. That's one thing the rust community has to get right. async/await was supposed to be that, but it's only a protocol to define what blocks/doesn't and when you allow context switching. An event loop also has the notion of scheduling, getting a reference to what is scheduled, request the result or error on said scheduled thing, or cancel it. And even loop must bridge different implementations of concurrency (e.g: asyncio.run_in_executor). An event loop also has a life cycle, which includes at the very least a setup and a tear down. An event loop must integrates in an environment, like what do you do when you have several loops, or if you run one loop per threads ? So you need to define a general behavior for all that. Then let anyone write the implementation the way they want.
  - steveklabnik 8y ago
    That’s all of this: https://doc.rust-lang.org/nightly/core/task/ https://doc.rust-lang.org/nightly/core/task/
    - sametmax 8y ago
      That's an API. Like asyncio in Python is an API. If you make the event loop swapable without making this API mandatory however, it's never going to be a protocol.
      - steveklabnik 8y ago
        The api is mandatory; it’s how async/await works.