(1) I noted “tens of thousands of clients” etc. If you’re writing a program that’s supposed to be used (like most web-apps) by short-lived concurrent client requests in typical transaction-processing fashion, there’s no good reason to use monadic concurrency: pthreads is fine.
(2) monadic I/O is better when you have threads that don’t do I/O, and context-switching overheads dominate actual work. But when your threads are doing actual work, no.
there are a lot of people that would disagree with this statement, in the abstract.
In theory, there is no difference between theory and practice. In practice, it always depends on what you’re doing. I went back and looked at this thread, ( Lwt vs System threads - #14 by ivg ) and the only benchmark mentioned is “Chinese whispers”. I mean … what bullshit: there’s only one real-world case that corresponds, and that’s writing a pub/sub messaging engine. Yeah, sure: if I’m writing one of those, I’m going to use an event-loop-based design. But for a web-server? Of course not. A web-application server with significant traffic will always have a front-end “real web server” to serve static content and absorb network security attacks. So the web-app-server should be receiving only full requests, with all buffering happening in the front-end web server.
The relevant benchmark is not “chinese whispers” or any other concurrency benchmark The relevant benchmark is the overhead in reading characters from a file, one-by-one, thru the monadic I/O stack, vs using direct-style. Because that’s what your web-server is going to be doing.
I want to re-emphasize: YES there are situations where you need monadic I/O. Sure. But for almost all code, that’s not the case. The real argument for using monadic I/O is that you can see where your code gets time-sliced, so the chance of surreptitious time-slicing-induced bugs is lower. But then if you go and run multiple threads to execute your promises, you just threw that out the window.