Manually scheduling threads seems like a really shitty way to program
But regardless, the GP post was not taking about matrix math, it seems it was talking about sending an HTTP request and waiting for a response, which is something that actually is I/O bound on the TCP socket.
> "I don't want an async model, which assumes you're I/O bound, interfering with keeping all those CPUs busy."
Strongly implies to me that there's a CPU-bound component there.
>Cooperative multitasking is used with await in languages with a single-threaded event-loop in their runtime, like JavaScript or Python.
There's no reason rust can't have an executor that does the same, and you only use that within the event loop on your one or two HTTP worker threads. If you're waiting in a thread for an HTTP request to return, that's never going to be CPU-bound. I still am failing to see what the problem here is besides a complaint about some rust crate only supporting a multi-threaded executor, which again is a different problem than whether it's done with async futures or not. One could just as easily write some C code that forces the use of threads.
The goal is to NOT do what you're suggesting. It's a holdover from when native threads were much more expensive than they are today, and multiple cores on a single cpu were rare.