Hacker News new | ask | show | jobs
by Yoric 332 days ago
While this is indeed the most common use, I'll bring as counter-examples Rust (or C#, or F#, or OCaml 5+) that supports both OS threads and async. OS threads are good for CPU-bound tasks, async for IO-bound tasks.

The main benefit of having async (or Go-style M:N scheduling) is that you can afford to launch as many tasks/fibers/goroutines/... as you want, as long as you have RAM. If you're using OS threads, you need to pool them responsively to avoid choking your CPU with context-switches, running out of OS threads, running out of RAM, etc. – hardly impossible, but if you're doing more than just I/O, you can run into interesting deadlocks.
1 comments
wasmperson 332 days ago
> The main benefit of having async (or Go-style M:N scheduling) is that you can afford to launch as many tasks/fibers/goroutines/... as you want

Some have argued that the real solution to this problem is to "just" fix OS threads. Rumor has it Google has done exactly this, but keeps it close to their chest:

https://www.youtube.com/watch?v=KXuZi9aeGTw

https://lwn.net/Articles/879398/

Somewhat related and also by Google is WebAssembly Promise Integration, which converts blocking code into non-blocking code without requiring language support:

https://v8.dev/blog/jspi

I see a possible future where the "async/await" idea simply fades away outside of niche use-cases.

link
Yoric 332 days ago
I think that PI will have a role, but I suspect that it can quickly destroy the performance of wasm code in unexpected ways.

As for fixing OS threads, indeed, this may very well change the ecosystem, but many developers expect their code to be cross-platform, so it might take a while before there is a solution that works everywhere.

link