3 ms·

Ok, let's chalk it up as a miscommunication for the most part, I'm sorry for calling your comment "very wrong". We can agree that it was incomplete/imprecise, r

Ok, let's chalk it up as a miscommunication for the most part, I'm sorry for calling your comment "very wrong". We can agree that it was incomplete/imprecise, right? It got explained, so let's move on :) But, I take issue with one more bit here: > But they're also the easiest. I don't believe that's true. Threads are the easiest to work with if you have a lot of shared, mutable state kept within an adress space of a single process and, crucially, cannot do anything about it. I don't know if that's the case for HN backend, but it rarely is in practice. Then there's a problem of multiple different threading implementations out there, and also an issue of how the threading mechanisms interact with the runtime (Python is multithreaded, but has a GIL). Frankly, it's a minefield on all sides, and implementing a system that is multithreaded, performant, and correct at the same time is the exact opposite of what I'd call "easy". That's also the reason why I disagree here: > If you see a statement that code can't even do that, then that should already imply that you can't run multiple processes To me, threads are not the first thing that comes to mind when I think about parallelism. Being unable to leverage threads, to me, is a good thing: just let this sleeping can of worms lie. As you know, there are multiple (many) ways of achieving parallelism, and they differ very much: I don't think being unable to leverage one of them says anything about the ability to use any of the others. That may be just me, though, so let's just say I have a different impression here and call it a day :)

Dylan16807 5y ago
Sure, very little to disagree with, and moving on is fine, but I do want to make one small note: the reason I say threads are easier is that in almost every case you can take a multi-process model and turn it into an efficient multi-thread model with minimal effort. Threads give you more tools, and a lot of those tools are slow. And if a type of parallelism won't work with threads, it very likely won't work with anything else.

Dylan16807 5y ago

Sure, very little to disagree with, and moving on is fine, but I do want to make one small note: the reason I say threads are easier is that in almost every case you can take a multi-process model and turn it into an efficient multi-thread model with minimal effort. Threads give you more tools, and a lot of those tools are slow. And if a type of parallelism won't work with threads, it very likely won't work with anything else.