I think you're spot on. For 99% of the use cases, traditional threads are the way to go. It's only when you have a truly massive number of logical threads (>100k, or even >1M) not doing anything most of the time, that OS threads reach their limits due to their aggregate stack size. In other words: web services, where each server thread either waits for input from the client or for a database reply, and only if they have to handle hundreds of thousands of concurrent clients.

This is not a concern for most Rust users, but it is a concern for large companies that are potential patrons of an up-and-coming programming language. I'm not saying it's wrong to cater to their needs, rather that it's not something over which regular Rust users should lose sleep.

You're right but even most big players can probably just use threads. If you are serving 1 million clients per VM you are probably taxed for other resources besides threads unless 99.99% of your clients are guaranteed to idle.

Things that are easier with Rust's async:

• Timeouts and cancellation. Rust's async code can be aborted from the outside (with correct cancellation and cleanup of everything in progress). OTOH if you run imperative blocking code, you need every blocking function to cooperate.

• Full utilization of CPU and I/O in workloads that mix both. Async executor balances threadpools/polling queues for these automatically. OTOH if you just use regular blocking calls with no state machines/continuations, it will be hard to separate these two. A single mixed-use threadpool will oscillate between I/O-bound threads and underutilizing CPU, and CPU-bound threads and idling I/O.

Fully agree with that, and Rust makes that very easy still. Its 5-10 lines to spawn multiple threads that communicate with each other either via shared state or message passing, and I solve most paralleism problems that way to this day in Rust. :D