3 ms·

> Asynchronous programming is a great fit for IO-driven programs Yeah, but this could already be solved without "async/await compiler magic" in native code jus

> Asynchronous programming is a great fit for IO-driven programs Yeah, but this could already be solved without "async/await compiler magic" in native code just with OS primitives, for instance with Windows-style event objects, it might look like this in pseudo-code: const event1 = read_async(...); const event2 = read_async(...); const event3 = read_async(...); wait_all(event1, event2, event3); This would run three IO operations "in parallel", and you're waiting for all three to finish until execution continues after the wait_all() call. Looks just as convenient as async/await style, but doesn't need special language features or a tricky code-transformation pass in the compiler which turns sequential code into a switch-case state machine (and most importantly, it doesn't have the 'function-color problem'). (this really makes me wonder why Rust has gone down the Javascript-style async/await route with function coloring - the only reason why it remotely makes sense is that it also works in WASM).

deleted 3y ago
[deleted]
pavlov 3y ago
But the difference is that wait_all() is blocking the thread, right? Or does it keep running the event loop while it's waiting, so callbacks for other events can be processed on the same thread? If it does the latter, the stack will keep growing with each nested wait call: main -> runEventLoop -> someCallback -> wait_all -> runEventLoop -> anotherCallback -> wait_all -> ... The async/await transformation to a state machine avoids this problem.
- flohofwoe 3y ago
  Yeah it blocks the thread, any other "user work" needs to happen on a different thread. But if you just need multiple non-blocking IO operations run in parallel it's as simple as it gets. (the operating system's thread scheduler is basically the equivalent to the JS "event loop").
  - pavlov 3y ago
    Desktop operating systems all have application event loops that run within a single thread because the OS thread scheduler is not the same thing. If you just want an event loop, trying to use threads instead for everything will often end up in tears due to concurrent data access issues.
    - flohofwoe 3y ago
      An async/await runtime doesn't necessarily need to run everything on the same thread though (that's really just a Javascript runtime restriction), instead it could use a thread pool. In this case, the same concurrent data issues would apply.
      - gloryjulio 3y ago
        Yes, basically golang model
    - mpweiher 3y ago
      Use one or more service threads to do most work off the UI thread.
      - pavlov 3y ago
        Yes, sure. Operating systems nowadays provide useful thread pool runtimes for this purpose, like Apple’s GCD. In no way does it mean that you don’t need an event loop because threads exist, as was the contention here.
        mpweiher 3y ago
        1. You don't need either thread pools or GCD for this. GCD generally makes things worse. 2. It absolutely does mean you don't need the main thread event loop for non UI-events.
  - mrfox321 3y ago
    Right, so it's less efficient than async. Async would let you yield at the gather.
bluejekyll 3y ago
> this really makes me wonder why Rust has gone down the Javascript-style async/await route with function coloring - the only reason why it remotely makes sense is that it also works in WASM As someone who’s done asynchronous programming in Rust before Futures (I’ll call it C style), then with Futures, then with async/await, it’s because it is far simpler. On top of that it allows for an ecosystem of libraries to be built up around common implementations for problems. Without it, what you end up with is a lot of people solving common state machine problems in ways that have global context or other things going on which make the library unportable and not able to easily be reused in other contexts. With async/await, we actually have multiple runtimes in the wild, and common implementations that work across those different runtimes without any changes needed. So while I’m disappointed that we ended up with function coloring, I have to say that it’s far simpler than anything else I’ve worked with while maintaining zero overhead costs allowing it to be used in nostd contexts like Operating Systems and embedded software.

deleted 3y ago

[deleted]

pavlov 3y ago

But the difference is that wait_all() is blocking the thread, right? Or does it keep running the event loop while it's waiting, so callbacks for other events can be processed on the same thread? If it does the latter, the stack will keep growing with each nested wait call: main -> runEventLoop -> someCallback -> wait_all -> runEventLoop -> anotherCallback -> wait_all -> ... The async/await transformation to a state machine avoids this problem.

flohofwoe 3y ago
Yeah it blocks the thread, any other "user work" needs to happen on a different thread. But if you just need multiple non-blocking IO operations run in parallel it's as simple as it gets. (the operating system's thread scheduler is basically the equivalent to the JS "event loop").
- pavlov 3y ago
  Desktop operating systems all have application event loops that run within a single thread because the OS thread scheduler is not the same thing. If you just want an event loop, trying to use threads instead for everything will often end up in tears due to concurrent data access issues.
  - flohofwoe 3y ago
    An async/await runtime doesn't necessarily need to run everything on the same thread though (that's really just a Javascript runtime restriction), instead it could use a thread pool. In this case, the same concurrent data issues would apply.
    - gloryjulio 3y ago
      Yes, basically golang model
  - mpweiher 3y ago
    Use one or more service threads to do most work off the UI thread.
    - pavlov 3y ago
      Yes, sure. Operating systems nowadays provide useful thread pool runtimes for this purpose, like Apple’s GCD. In no way does it mean that you don’t need an event loop because threads exist, as was the contention here.
      - mpweiher 3y ago
        1. You don't need either thread pools or GCD for this. GCD generally makes things worse. 2. It absolutely does mean you don't need the main thread event loop for non UI-events.
- mrfox321 3y ago
  Right, so it's less efficient than async. Async would let you yield at the gather.

bluejekyll 3y ago

> this really makes me wonder why Rust has gone down the Javascript-style async/await route with function coloring - the only reason why it remotely makes sense is that it also works in WASM As someone who’s done asynchronous programming in Rust before Futures (I’ll call it C style), then with Futures, then with async/await, it’s because it is far simpler. On top of that it allows for an ecosystem of libraries to be built up around common implementations for problems. Without it, what you end up with is a lot of people solving common state machine problems in ways that have global context or other things going on which make the library unportable and not able to easily be reused in other contexts. With async/await, we actually have multiple runtimes in the wild, and common implementations that work across those different runtimes without any changes needed. So while I’m disappointed that we ended up with function coloring, I have to say that it’s far simpler than anything else I’ve worked with while maintaining zero overhead costs allowing it to be used in nostd contexts like Operating Systems and embedded software.