> I think it was popular because it was easy to code to. That's not that unlike it being easy to implement. > Multi-threaded coding is easy to get wrong, [...

> I think it was popular because it was easy to code to. That's not that unlike it being easy to implement. > Multi-threaded coding is easy to get wrong, [...] Yeah, but the better design is async/await and so on, not threading, but that stuff was not very popular in the 80s. The approach to concurrency in the 80s was heavy on context switching because that's what was inherited from the 70s. It feels like the thinking was along the lines of "during the time you're waiting for a response some other process will run, and since we're used to heavy latency, who cares!", but that became less and less tenable. There's a reason all the distributed operating system research of the 80s died except for filesystems -- with filesystems you can consciously avoid hot ping pong by just not accessing shared resources concurrently, while the filesystem itself remains super useful.