Live data from Hacker News

Async-await on stable Rust

blog.rust-lang.org

391–392 of 392 posts

Re: Async-await on stable Rust

#391
post #112

Earlier quoted context omitted.

> 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?

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.

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.

Re: Async-await on stable Rust

#392

Earlier quoted context omitted.

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 conc…

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.

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/
Post reply on HN