> Just use thread pool Rust's Tokio runtime uses a thread pool. As does C#'s asynchronous runtime. Goroutines are also multiplexed among threads. Asynchrono

> Just use thread pool Rust's Tokio runtime uses a thread pool. As does C#'s asynchronous runtime. Goroutines are also multiplexed among threads. Asynchronous primitives and multithread programming are not mutually exclusive, Javascript not withstanding. Interestingly, one language is indeed bucking the trend. Java is introducing fibers (lightweight user-mode threads) that allow traditional (sane, as you call it) code to be efficiently scheduled so that it "performs as well as asynchronous code" without introducing new language primitives. So you'll have the opportunity to see which works best in important mainstream languages. One wonders if Java won't pull off a surprise win here. > you should think about scalable architecture to be able to scale to multiple machines No, sorry; that's not a viable approach. CPUs are highly concurrent beasts with dozens of cores. Using these inefficiently with traditional blocking threads is not feasible even if you can spread the inefficiency across "multiple machines." That would simply waste expensive hardware, power, space and cooling. Asynchronous techniques solve real efficiency problems in the real world; it isn't a fad. And you can't fall back to "most projects don't need it" in the context of advising others how to scale large systems; they do indeed "need it" and they will continue to gravitate to programming platforms that provide it while abandoning those that do not.