5 ms·

Thread-based concurrency has no future. It's complex and it doesn't scale beyond a certain point. Process-based concurrency is relatively simple (especially if

Thread-based concurrency has no future. It's complex and it doesn't scale beyond a certain point. Process-based concurrency is relatively simple (especially if your programming language has good async support) and it can scale indefinitely. The one advantage of threads is that the overhead is lower when operating at low concurrency. But it's like algorithmic complexity, people only care about growth in complexity not about the initial offset.

jerf 11y ago
"Process-based concurrency is relatively simple (especially if your programming language has good async support)" You can have "process-based concurrency... simple" or "good async support" but you can't have both... good async support becomes not simple. "Good async support" in a single process just means you pretty much have virtual threads anyhow, you just don't formally label them. That's why all the "good async" languages are basically structuring all their "good async" support so that you can write code that looks and behaves... virtually exactly like threads. The problem with threads isn't the threads... it's the sharing patterns. Lots of nested locks is insane. But that's not the only way to do it. Even in Go it isn't that hard to do things sanely, and things like Erlang and Rust make it even easier. If you've still only used those languages with "good async support", you really ought to try one of the modern languages that are the real competition. I have not heard very many people become fluent in one of those and then want to go back.
- sportanova 11y ago
  what are the modern languages that are the real competition?
- woah 11y ago
  Wondering what your opinion on JavaScript's async support is? Huge amounts of flawlessly async single threaded code have been written in js.
incepted 11y ago
> Thread-based concurrency has no future. It's complex and it doesn't scale beyond a certain point. Beyond what point? Every single company that handles petabytes of data, starting with Google, seems to be scaling just fine with thread-based concurrency. And why shouldn't they? Thread-based concurrency has decades of study behind it, it's very well understood, the tooling is terrific (IDE's even tell you ahead of time when deadlocks can happen and when they do, they can tell you exactly why) and the performances are unmatched. I'd say thread-based concurrency is going to be around for a while, as opposed to the many fads that come and go trying to replace it, starting with actor-based concurrency and transactional memory.
- icebraining 11y ago
  Nothing like replying hyperbole with more hyperbole. Calling the actor model, which has been around for forty years and has been slowly gaining recognition, a "fad" is frankly ridiculous.
- jondubois 11y ago
  We haven't yet seen the limits of thread-based concurrency because CPUs have only just started to scale-out (by adding more cores). You're not going to experience any issues if you just have a small number of threads spread out over a small number of cores. If you had like 100+ cores (just guessing) and several of them tried to access or write to a specific shared memory location, they would spend a lot of time busy-waiting for each other to finish (assuming you're using mutexes). Maybe using semaphores could work but your code will end up looking like a mess. With process-based concurrency, each process can only rely on its own memory pool, so that does use-up more memory, but processes are fully independent from each other (fully parallel) so no time is wasted busy-waiting for anything. See https://en.wikipedia.org/wiki/Amdahl%27s_law https://en.wikipedia.org/wiki/Amdahl%27s_law

jerf 11y ago

"Process-based concurrency is relatively simple (especially if your programming language has good async support)" You can have "process-based concurrency... simple" or "good async support" but you can't have both... good async support becomes not simple. "Good async support" in a single process just means you pretty much have virtual threads anyhow, you just don't formally label them. That's why all the "good async" languages are basically structuring all their "good async" support so that you can write code that looks and behaves... virtually exactly like threads. The problem with threads isn't the threads... it's the sharing patterns. Lots of nested locks is insane. But that's not the only way to do it. Even in Go it isn't that hard to do things sanely, and things like Erlang and Rust make it even easier. If you've still only used those languages with "good async support", you really ought to try one of the modern languages that are the real competition. I have not heard very many people become fluent in one of those and then want to go back.

sportanova 11y ago
what are the modern languages that are the real competition?
woah 11y ago
Wondering what your opinion on JavaScript's async support is? Huge amounts of flawlessly async single threaded code have been written in js.

incepted 11y ago

> Thread-based concurrency has no future. It's complex and it doesn't scale beyond a certain point. Beyond what point? Every single company that handles petabytes of data, starting with Google, seems to be scaling just fine with thread-based concurrency. And why shouldn't they? Thread-based concurrency has decades of study behind it, it's very well understood, the tooling is terrific (IDE's even tell you ahead of time when deadlocks can happen and when they do, they can tell you exactly why) and the performances are unmatched. I'd say thread-based concurrency is going to be around for a while, as opposed to the many fads that come and go trying to replace it, starting with actor-based concurrency and transactional memory.

icebraining 11y ago
Nothing like replying hyperbole with more hyperbole. Calling the actor model, which has been around for forty years and has been slowly gaining recognition, a "fad" is frankly ridiculous.
jondubois 11y ago
We haven't yet seen the limits of thread-based concurrency because CPUs have only just started to scale-out (by adding more cores). You're not going to experience any issues if you just have a small number of threads spread out over a small number of cores. If you had like 100+ cores (just guessing) and several of them tried to access or write to a specific shared memory location, they would spend a lot of time busy-waiting for each other to finish (assuming you're using mutexes). Maybe using semaphores could work but your code will end up looking like a mess. With process-based concurrency, each process can only rely on its own memory pool, so that does use-up more memory, but processes are fully independent from each other (fully parallel) so no time is wasted busy-waiting for anything. See https://en.wikipedia.org/wiki/Amdahl%27s_law https://en.wikipedia.org/wiki/Amdahl%27s_law