> There's not as much of a culture of writing APIs that way in Python because it's generally a terrible way to program
I would love to see evidence for you making that statement. Almost every programmer would put out their fav programming language as the 'right' way to program.
> everything except HTTP servers with absurd numbers of concurrent connection
Once you introduce async operations in your code - you need to follow the execution path through. http request can be async - but then what if the http request results you doing a db lookup or some form of file handling ? you need to make the whole thing event driven.
It's not like we didn't have cooperative multitasking for 50 years. Having threads/processes and a scheduler is easier and safer, full stop. Potentially long-running portions of the program don't need to be arbitrarily chopped up to yield control back to the server, because they are pre-empted. Your system is no longer at the mercy of the worst code within it.
Both nginx and Apache's event MPM handle HTTP connections with events while the app backends are still using preemptive threads for running the HTTP handler code, so it's clearly not the case that "you need to make the whole thing event driven." You just need programmers who don't think, "well since the browser doesn't expose threads to JavaScript programmers, clearly they are useless."
I would love to see evidence for you making that statement. Almost every programmer would put out their fav programming language as the 'right' way to program.
> everything except HTTP servers with absurd numbers of concurrent connection
Once you introduce async operations in your code - you need to follow the execution path through. http request can be async - but then what if the http request results you doing a db lookup or some form of file handling ? you need to make the whole thing event driven.