Thank you. I was including futures promises in my mention of async/await because that's how I use them mostly. I couldn't remember where I got some confirmation about my understanding, but since found it in my bookmarks. It seems to me that Haskell programmers want to abstract away the machine and this makes me wonder how well this works with practical concerns of controlling the computer to make it work. I look forward to learning more:

"async/await is just the do-notation of the Promise monad" https://gist.github.com/MaiaVictor/bc0c02b6d1fbc7e3dbae838fb...

Haskell programmers generally believe in making it clear what the code means and letting the compiler/runtime figure out the details of how to execute it. A perfect programmer with infinite time could almost certainly get more optimal behaviour by specifying all the details; on the other hand, a language that expects the programmer to specify all the details gives them plenty of opportunity to get those details wrong, or for their choices to become outdated.

In my experience Haskell significantly outperforms C++ on real-world business problems with realistic development effort (as opposed to carefully tuned microbenchmarks). I do think laziness was a mistake (to the point that one of the biggest industrial deployments uses a strict variant instead). I've spent most of my career doing work in Scala that's very much real-world, so as far as I'm concerned all the people talking about these things being academic or overly abstract are talking crap - I use this stuff every day, and whenever I've tried to take a shortcut (e.g. define a slightly law-breaking monad instance, abuse some mutable state somewhere) I've come to regret it later.