> It is gratuitous to take the word "simpler" as some kind of proof that the person you are responding to is an ignorant who uses objectively bad tools. Given

> It is gratuitous to take the word "simpler" as some kind of proof that the person you are responding to is an ignorant who uses objectively bad tools. Given that you subsequently make the point that most toolkits are bad, I think my assumption was safe. But let's not lose the plot here, process-level parallelism makes sense in many cases. It's just not a valid replacement for per-process concurrency and it is most definitely not "simpler." Your failure modes become incredibly complex and varied, and that was my only point here. More modern environments–the ones you should be using unless you have a compelling reason to do otherwise–use shared-state concurrency as a platform for higher level abstractions. But this is still "multicore in-process parallelism" and the underlying model is still threading. Building abstractions on top of in-process parallelism is not rejecting the underlying layer, it's embracing it. If you are not using modern tools, then yeah correct concurrency is hard and variable degrees of underlying parallelism only exacerbate that. It is also hard to start fires with just flint, steel and tinder. New topic, please. So I'm not sure what you're taking exception to other than your perception of my tone.