6 ms·

Actually, it's only "simpler" in that you are familiar with it and perhaps your programming environment of choice lacks good support for multi-threaded programm

Actually, it's only "simpler" in that you are familiar with it and perhaps your programming environment of choice lacks good support for multi-threaded programming. It's certainly not "simpler" from the perspective of resource efficiency (e.g., it's so easy to spoil Copy-on-Write's benefits) and usually it asks some other process to do the hard work of coordination. From the perspective of correctness, introducing multiple processes to your system greatly increases the number of failure states and vastly complicates error recovery. I think you're dismissing the state of the art on multiple fronts, as is the article. From single-variable STM (of which Haskell and Clojure both have excellent implementations) to battle-tested and well-understood concurrency primitives in the Java standard concurrency library, multi-threaded programming is more approachable and performant now than it has ever been. But the article is oddest in that it seems to hold up Erlang as a way forward, but Erlang is just a different model built on top of thread-based concurrency. If the argument is the old pthread-ish model of "1 thread per call" and very primitive synchronization tools are antiquated... then who is he arguing with? Erlang uses actors, Haskell uses sorcery (really, it's fancy; they turn normal-looking threaded code into erlang-ish sliced execution under the covers), Go uses fancy structures along with coroutines, Java uses Executors to implement higher-level work off patterns, and everyone is using Futures and Promises now.

slurgfest 14y ago
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. Reality is less clear. "Simpler" clearly referred to the complexity and the mess created by synchronization in a shared-everything environment, which is where most languages are at with threading (Haskell, Clojure and Erlang are not most languages). This is a valid criticism. You may lose Copy-on-Write, but sharing everything by default, at a low level, does raise the need for complex synchronization, which has its own performance issues. And this is very good reason to explore and use other concurrency models. This is something that you and the article and the person you are responding to all seem to agree on. Except that you seem to take any interesting concurrency interface to be threading (no, goroutines are NOT threads) and you draw the strange moral that only the complex problems of threads can be addressed with nice tools and new ideas, but somehow not the problems of other basic concurrency models. Assuming we have available helpful interfaces for using processes, threads and greenlets - all of which have been produced somewhere - the argument should be about the performance of the foolproofed backends. Preferably based on numbers.
- KirinDave 14y ago
  > 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.
aphyr 14y ago
Minor note: Clojure's STM applies to any number of variables.
- KirinDave 14y ago
  I only meant it in contrast to whole-memory STM, which has had a lot of problems in the literature not being slow as a dog. I blanked on the term, and I welcome the correction...
blaforge 14y ago
For another perspective, you should take a look at JActor. https://github.com/laforge49/JActor https://github.com/laforge49/JActor JActor is a high-throughput JAva actor framework capable of delivering up to 200 million messages per second on an i7. It achieves this by operating synchronously whenever it can. The main innovation here is what I call commandeering, which allows an actor to process the message sent to another actor in the same thread--so long as the target thread is idle.

slurgfest 14y ago

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. Reality is less clear. "Simpler" clearly referred to the complexity and the mess created by synchronization in a shared-everything environment, which is where most languages are at with threading (Haskell, Clojure and Erlang are not most languages). This is a valid criticism. You may lose Copy-on-Write, but sharing everything by default, at a low level, does raise the need for complex synchronization, which has its own performance issues. And this is very good reason to explore and use other concurrency models. This is something that you and the article and the person you are responding to all seem to agree on. Except that you seem to take any interesting concurrency interface to be threading (no, goroutines are NOT threads) and you draw the strange moral that only the complex problems of threads can be addressed with nice tools and new ideas, but somehow not the problems of other basic concurrency models. Assuming we have available helpful interfaces for using processes, threads and greenlets - all of which have been produced somewhere - the argument should be about the performance of the foolproofed backends. Preferably based on numbers.

KirinDave 14y ago
> 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.

aphyr 14y ago

Minor note: Clojure's STM applies to any number of variables.

KirinDave 14y ago
I only meant it in contrast to whole-memory STM, which has had a lot of problems in the literature not being slow as a dog. I blanked on the term, and I welcome the correction...

blaforge 14y ago

For another perspective, you should take a look at JActor. https://github.com/laforge49/JActor https://github.com/laforge49/JActor JActor is a high-throughput JAva actor framework capable of delivering up to 200 million messages per second on an i7. It achieves this by operating synchronously whenever it can. The main innovation here is what I call commandeering, which allows an actor to process the message sent to another actor in the same thread--so long as the target thread is idle.