One of the question asked but not answered is "why is more/less expensive to use threads/coroutines?" This is my attempt to the answer: (related to working in

One of the question asked but not answered is "why is more/less expensive to use threads/coroutines?" This is my attempt to the answer: (related to working in a database engine and there you also get "why is not a good idea to let the OS handle things for you".) - Is partially historical - ... and change it could break in funny ways (you bet code depend in this numbers in code somehow!) - And this is because this is a GLOBAL choice for all the apps running, so the OS is blind to what could be optimal (and even if you can tweak it the OS CAN'T optimize for that rare event) - It must work across many workloads - MOST code run Process-> Small threads and CPU intensive taks (ie: "I pay $$$$$ for a thread-ripper and my app is equally slow!") And probably the #1: - The main switch is 1 UI thread * Small-N background threads, so is better to pre-allocate for "bigger" capacity --- Then, "why coroutines and similar are better?" (Is easier to see when you implement it (coroutines) but lets ignore that and use the same mental framework as above) - Even a "general" purpose language have a more defined role ("Go is for networking apps") and this leak, strongly, if this lang is biased for coroutines/other OR threads (Note how Rust can't because the role for it is as broad as a full OS) - Langs that use coroutines/other VS Threads are optimized for high concurrency because is expected that the developers WILL create significant libraries/frameworks for the smaller subset of high concurrency apps (like web servers) - Langs that use Threads VS coroutines/other are more general in purpose (Rust, Java, ...) or need to run faster for CPU-intensive/Parallel code and there Threads are in fact faster than coroutines.