dupedon Hacker News • Recommends
On “Understanding Concurrency, Parallelism and JavaScript”
If you prefer to learn by video, here's an excellent talk on the same subject by Rob Pike that I link all the time to people link to this video
0:00 / 0:00
Concurrency is not Parallelism by Rob Pike
gnbitcom
5.9K subscribers • 3 videos on Hallway
- Recommended by 5 people: 4 on Hacker News and 1 curated list.
- A classic. People kept recommending it from 2021 to 2025.
- Presented by Rob Pike
Intermediate. Assumes working knowledge.
190K views10 years ago5 recommendations
Programming languagesSystems programmingConcurrency and parallelismGo
Rob Pike explains the fundamental distinction between concurrency as a way to structure a program and parallelism as simultaneous execution.
Slides: talks.golang.org/2012/waza.slideWhy it's here
5 people recommend thisWhat people say. Widely recommended by engineers as the definitive explanation of concurrency versus parallelism and the design philosophy of Go.
Moments people linked to
programming-talkscurated list on GitHubRecommends
Under “Go”
Concurrency Is Not Parallelism 00:31:22 by **Rob Pike** (2012)
merbon Hacker News • Recommends
On “Althttpd: Simple webserver in a single C file”
yeah, basically. a lot of people do not know, but async/await does have NOTHING do to with threads or processes. you can use threads with async/await, but you do not. async/await basically means you are running your "green threads"/tasks/promises on a event loop, the event loop can be either single threaded or it can run the stuff on multiple threads. a lot of people just did not get the difference between concurrency vs. parallelism. threads and processes are basically parallelism, while concurrency is async programming. good talk about that stuff from rob pike (go): link to this video
cratermoonon Hacker News • Recommends
On “Ask HN: Kubernetes Worth It?”
Anyone that can wrap their mind around the model of Communicating Sequential Processes1 implemented using channels in Go will improve their programming. See also Concurrency is not Parallelism by Rob Pike: link to this video After I figured it out, I spent a good month writing personal projects to play with channels and concurrency and get the "these are cool I'm going to use them everywhere" urge out of my system. 1 link
auxiliarymooseon Hacker News • Recommends
On “Thoughts on Go vs. Rust vs. Zig”
Agreed. Rob Pike presented a good talk "Concurrency is not Parallelism" which explains the motivations behind Go's concurrency model: link to this video Between the lack of "colored functions" and the simplicity of communicating with channels, I keep surprising myself with how (relatively) quick and easy it is to develop concurrent systems with correct behavior in Go.
u/anxiousmarcusin r/dotnet • Mentions
…any interviews where the candidates get awfully confused about even very basic use cases.
To people who are unclear about this, let me put this very bluntly with a commonly used analogy. I'm gonna use super simple examples so everyone can benefit. If you're advanced, please ignore this post.
u/Daell provided this link with detailed explanation - link to this video
**SCENARIO**
Think of your server as a Chef and think of making an egg, blending a smoothie, frying some chicken as tasks.
The idea is Chef gets a request to make eggs, blend smoothie and fry some chicken. He gets them done.
***WITHOUT CONCURRENCY***
Chef gets a request to make an egg, chef starts making an egg. Chef gets another reque…
u/desiInMuricain r/Kotlin • Mentions
On “Read this to understand the difference between concurrency and parallelism (with Kotlin)”
Great read. The link to the amazing talk in that article is broken.
This is the talk about Concurrency is not parallelism by Rob Piker
Edit: The highly recommended paper from above talk:
Communicating sequential processes
dupedon Hacker News • Mentions
On “Async I/O for Dummies (2018)”
As with all benchmarks, benchmark your workload. The tech empower stuff is gamed, like all rankings. But first and foremost, concurrency is not parallelism 1. In my practical experience dealing with both, asycn is a language semantic for concurrency, threads are an OS feature for parallelism. It's a little nonsensical to ask the pros/cons since they are different entirely ; you can use both at the same time (and in practice most async implementations use threads) 1 link to this video "Concurrency is not Parallelism" talk by Rob Pike.
ly3xqhl8g9on Hacker News • Mentions
On “What Is Systems Programming, Really?”
Sure, but the context is very important: you can use Rust to control the DOM from WASM 1 and then you can use Haskell to write a load balancer 2. 1 link 2 link (off-topic: Rob Pike's Concurrency is not Parallelism link to this video )
u/luuuzetain r/compsci • Mentions
On “Collecting the greats, any suggestions?”
> Communicating Sequential Processes by C.A.R. Hoare
From Rob Pike: *"... if anything out of this talk sinks in is that you should go home and read that paper, it's absolutely amazing but based on that a lot of people with lesser minds have followed and built tools to use his ideas in concurrent languages..."*
u/bonekeeperin r/C_Programming • Mentions
On “In C, is it possible to run two different functions simultaneously?”
Yes it can, if you have two functions running on different threads. When they try to read/write to the same place at the same time, bad things happen.
This is a talk about concurrency and parallelism which is related to what you're asking (in Go, not C, but the concepts are the same, just think of "goroutines" as threads in C)