I interpret it as shared state concurrency. That is, multiple threads sharing the same address space performing reads and writes on shared data: atomics, mutexes, etc. From the update I understand that he's considering things like Actors, Communicating Sequential Processes (goroutines), and data partitioning divide+conquer (MapReduce) approaches as different even if they happen to be implemented on different threads sharing the memory space.

I'm not sure on the relative prevalence but I can say that I've read relatively little about what he's calling multi-threaded programming. Mostly just a handful of lock-free data structures from the C++ guys and Rust's take on how they can do it while avoiding data races due to the type system. The alternatives, on the other hand, have been on HN pretty much continuously since HN started up.

Programming that explicitly creates and manages threads.

I still think that he assessed this point favorably for himself. If you read the whole point he made he may be right. But for me all these asynchronous methods are used more and more, so I'd say multi-threaded programming is much bigger than it was 10 years ago.

If you look at some languages / frameworks I see now this: If you are programming now in C# you have keywords like "await" which make background processes much easiert.

When you are programming Android in AndroidStudio you are warned if you try to call a web service in a GUI thread.

15 years ago, when I've started programming commercially (MFC and C++) most of the books said something along "well this is multi-threaded programming, but 'There be dragons'.."

Anything around scaling across multiple cores I suppose. It wasn't as nuanced back then.

In 2004 single core computers were still quite prevalent, and the idea of steady significant performance improvements coming from increasing clock speeds was in its death throes. From memory it was about then that Intel had given up on the P4 Netburst architecture and stepped back to improving the P3 to release the new Core and Core Duo architectures.

Nowadays multicore has been reality for a long time and the number of cores in a CPU has increased a lot, and we're thinking much more about different competing ways of achieving better concurrency. Back then it was just about getting better multicore concurrency at all using bog standard threads.

My reading of it based on his grading is "preemptive multitasking with shared state"