4 ms·

I also think async (the paradigm) is kind of weird in rust world. I agree with https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ https:

by mamcx 7y ago

I also think async (the paradigm) is kind of weird in rust world. I agree with https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ https://journal.stuffwithstuff.com/2015/02/01/what-color-is-....

bryanlarsen 7y ago
All 5 of his points seem to be 2015 Javascript only. Some of them don't even apply to modern Javascript; I don't see any that apply to rust.
- vanderZwan 7y ago
  While I'm happy to believe you, with a short comment like that I just have to take your word for it. Could give a short explanation of how Rust already addresses each of these points for those of us who don't program in it?
  - littlestymaar 7y ago
    This article is 90% a rant against “callback hell” that js was facing before async/await was introduced. The remaining 10% stays valid even in the presence of async/await, but the trade-off (ignored by the article) of the alternative is having to manually deal with synchronization primitives (at least channels), which would make zero sense given that JavaScript is a single-threaded environment. Rust is a different beast, you can have whichever model you like best (OS threads, M:N threads (with third party libs), async/await) but async/await is by far the most powerful, that's why it's such a big deal that it lands on Rust stable.
pcwalton 7y ago
The solution suggested by that article is to use M:N threading, which was tried in Rust and turned out to be slower than plain old 1:1 threading. If you don't want to deal with async functions, then you can use threads! That's what they're there for. On Linux they're quite fast. Async is for when you need more performance than what 1:1 or M:N threading can provide.
- mamcx 7y ago
  > If you don't want to deal with async functions, then you can use threads! Truly? If some very popular lib become async (like actix, request, that I use), I can TRULY ignore it and not split my world in async/sync?
  - pcwalton 7y ago
    You can easily convert async to sync by just blocking on the result. The other way (sync to async) is more difficult and requires proxying out to a thread pool, but it's also doable.
    - BatmanAoD 7y ago
      An `async` function _can_ call blocking functions, of course, it just blocks the entire thread of execution which could otherwise continue making progress by polling another future.
  - nemothekid 7y ago
    Both actix and reqwest are already async, the fact that you haven't noticed yet just shows that you are already ignoring it.
    - mamcx 7y ago
      But the signatures are not. If them mark the types/functions async, what happened? I must rewrite all the calls?
      - pas 7y ago
        Async is just a syntactic sugar for Future<...>, you can poll() it manually. You can take the event loop, run it on one thread and do whatever you wish on other threads. Fearless concurrency, after all.
      - bluejekyll 7y ago
        you can just `.await` on any Future returned directly by APIs, if it's not marked as an async fn.
danShumway 7y ago
Author's solution is threads: > But if you have threads (green- or OS-level), you don’t need to do that. You can just suspend the entire thread and hop straight back to the OS or event loop without having to return from all of those functions. Correct me if I'm wrong, but wasn't the lack of threads one of the biggest reasons why NodeJS originally outperformed most of its competitors? Spinning up threads for each concurrent request was expensive, and (nonblocking) async code was by comparison ridiculously cheap, so the lack of overhead meant Node could just make everything async, instead of trying to decide up-front which tasks deserved which resources. Granted, it's been over a decade since Node came out. Maybe thread overhead has gotten a lot better? But barring faulty memory, I definitely remember a number of people explaining to me back then that being single-threaded was the point.
- IfOnlyYouKnew 7y ago
  I'm pretty sure that was the official talking point at the time, and some people may have even been motivated enough to actually belief it. Of course that all changed once Node got threads.
  - BatmanAoD 7y ago
    Did it, though? AFAIK Node still doesn't have OS threads, which are the expensive version. The "About" page still says that Node is "designed without threads": https://nodejs.org/en/about/ https://nodejs.org/en/about/

by mamcx 7y ago

bryanlarsen 7y ago

All 5 of his points seem to be 2015 Javascript only. Some of them don't even apply to modern Javascript; I don't see any that apply to rust.

vanderZwan 7y ago
While I'm happy to believe you, with a short comment like that I just have to take your word for it. Could give a short explanation of how Rust already addresses each of these points for those of us who don't program in it?
- littlestymaar 7y ago
  This article is 90% a rant against “callback hell” that js was facing before async/await was introduced. The remaining 10% stays valid even in the presence of async/await, but the trade-off (ignored by the article) of the alternative is having to manually deal with synchronization primitives (at least channels), which would make zero sense given that JavaScript is a single-threaded environment. Rust is a different beast, you can have whichever model you like best (OS threads, M:N threads (with third party libs), async/await) but async/await is by far the most powerful, that's why it's such a big deal that it lands on Rust stable.

pcwalton 7y ago

The solution suggested by that article is to use M:N threading, which was tried in Rust and turned out to be slower than plain old 1:1 threading. If you don't want to deal with async functions, then you can use threads! That's what they're there for. On Linux they're quite fast. Async is for when you need more performance than what 1:1 or M:N threading can provide.

mamcx 7y ago
> If you don't want to deal with async functions, then you can use threads! Truly? If some very popular lib become async (like actix, request, that I use), I can TRULY ignore it and not split my world in async/sync?
- pcwalton 7y ago
  You can easily convert async to sync by just blocking on the result. The other way (sync to async) is more difficult and requires proxying out to a thread pool, but it's also doable.
  - BatmanAoD 7y ago
    An `async` function _can_ call blocking functions, of course, it just blocks the entire thread of execution which could otherwise continue making progress by polling another future.
- nemothekid 7y ago
  Both actix and reqwest are already async, the fact that you haven't noticed yet just shows that you are already ignoring it.
  - mamcx 7y ago
    But the signatures are not. If them mark the types/functions async, what happened? I must rewrite all the calls?
    - pas 7y ago
      Async is just a syntactic sugar for Future<...>, you can poll() it manually. You can take the event loop, run it on one thread and do whatever you wish on other threads. Fearless concurrency, after all.
    - bluejekyll 7y ago
      you can just `.await` on any Future returned directly by APIs, if it's not marked as an async fn.

danShumway 7y ago

Author's solution is threads: > But if you have threads (green- or OS-level), you don’t need to do that. You can just suspend the entire thread and hop straight back to the OS or event loop without having to return from all of those functions. Correct me if I'm wrong, but wasn't the lack of threads one of the biggest reasons why NodeJS originally outperformed most of its competitors? Spinning up threads for each concurrent request was expensive, and (nonblocking) async code was by comparison ridiculously cheap, so the lack of overhead meant Node could just make everything async, instead of trying to decide up-front which tasks deserved which resources. Granted, it's been over a decade since Node came out. Maybe thread overhead has gotten a lot better? But barring faulty memory, I definitely remember a number of people explaining to me back then that being single-threaded was the point.

IfOnlyYouKnew 7y ago
I'm pretty sure that was the official talking point at the time, and some people may have even been motivated enough to actually belief it. Of course that all changed once Node got threads.
- BatmanAoD 7y ago
  Did it, though? AFAIK Node still doesn't have OS threads, which are the expensive version. The "About" page still says that Node is "designed without threads": https://nodejs.org/en/about/ https://nodejs.org/en/about/