4 ms·

Concur. Although perhaps the situation in Python could have been mitigated somewhat if a protocol was defined early that implementations could have adopted? Co

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.
      - sametmax 8y ago
        So everybody has to implement a task for any alternative event loop and accept tasks from other implementation ?
        pimeys 8y ago
        Yep. You build your event loop to take structs implementing the Future trait. The futures don't care about the executor, and it's easy to switch from an event loop running on the current thread to a thread pool, if needed.
        sametmax 8y ago
        Great. I wish we have done the same.

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.
    - sametmax 8y ago
      So everybody has to implement a task for any alternative event loop and accept tasks from other implementation ?
      - pimeys 8y ago
        Yep. You build your event loop to take structs implementing the Future trait. The futures don't care about the executor, and it's easy to switch from an event loop running on the current thread to a thread pool, if needed.
        sametmax 8y ago
        Great. I wish we have done the same.