Rob Pike – 'Concurrency Is Not Parallelism' [video] (2012)

Concurrency is a programming abstraction that conceptually allows multiple independent processes to run at the same time using scheduling. For example, running ten programs at once with only a single CPU. Concurrency is effectively CPU scheduling with maybe some other concepts of communication between processes for coordination.

Parallelism is running processes at the same time.

The driving motivation behind concurrency, as far as I can tell, is that it's a concept that can help reason about complex tasks with the added benefit of being able to take advantage of parallelism.

My problem with Pike's advocacy for concurrency, and Golang in particular, is that it's an abstraction that imposes a world view on what's a good programming paradigm and, more practically, how to take advantage of parallelism, both of which have limited utility compared with considering parallelism directly.

My opinion rather than some abstraction that imposes a world view on how to take advantage of parallelism, it's better to use how people actually take advantage of parallelism as a basis for abstraction.

I think Golang is a fine language but we now have 14+ years of hindsight to see how well it's fared and how much it's influenced the compute landscape. In my opinion, the "concurrency not parallelism" misses the simple issue that we want things to go fast. Which has had more influence, Golang's idea of concurrency or taking advantage of GPU parallelism? I think the answer is clearly taking advantage of GPU parallelism.

Slides - https://go.dev/talks/2012/waza.slide

It seems like we forgot about lightweight fibers for about 30 years and then collectively rediscovered it in about 2010. sure, Java did green threads, but not like m:n stuff.

I sometimes wonder where we would be now if people would have gone "Wow, mr Reppy! concurrentML is so cool!" in 1993.

instead we got pthreads and collective amnesia and later we got go's girly times and channels which are only half way there.

Why does Vimeo require me to verify my age in the UK to watch Robert Pike talking computer science?

After watching the video I can see how go lang makes it easier to write correct concurrent programs. But with AI writing the code these days, it is just as "easy" to write correct concurrent programs in Java (because AI is doing the work). Java's virtual threads are light weight, just like go's routines. Java's LinkedBlockingQueue offers roughly the same functionality as go's channels. I would like to hear from go experts as to why I am wrong. Does go have any inherent advantage if AI is writing the code?

To HN moderators: title needs to note that this talk is 13 years old.

Just set the source pile of C++ manuals on fire. No gophers needed!

it's an interesting talk, my take being:

concurrency _is_ parallelism, but for I/O. People often think of parallelism for the case of making something go faster - eg placing two computations in parallel (the definition posed in the video), OR placing two I/O operations in parallel - so this is the keyboard-vs-mouse in the OS, even when you're on one core only; this is multiple web requests in JavaScript, which does not support multi-threading, but 100% does support concurrency for I/O operations - that... badum-tiss! RUN IN PARALLEL.

I get the point of the talk, and it's well interesting, but I think it depends on how one views things.