Hacker News Reader

Yes, but in many many cases where people think they need to, there's actually a simpler and safer way to do it. Too many programmers see a long running task or an unresponsive UI and immediately declare that threads are the answer, when they're almost always not.

Admittedly they're much more likely to be useful now with so many spare cores on every machine, but they're still a hammer when most problems are screws.

How is anything other than threads supposed to be a solution to long-running tasks blocking the UI thread?

Which long running tasks?

Blocking IO? Switch to non blocking and events.

Long running computationally expensive work? Break it into small jobs and have your job queue be a priority queue.

At that point you're correct regardless of if you've got one thread or many servicing the queue. And generally the best way to take advantage of multiple cores os to have it be totally agnostic to the number of cores it's running on like this anyway.

IHMO, threads are mostly useful for scaling a workload beyond the capacity of a single core. For all other types of concurrency problems, a single thread of execution using some kind of event loop is usually a better fit.

Be reluctant to use threads.

"Cautious" is probably a better word. Be cautious when considering threads.