Concurrency is not Parallelism by Rob Pike
gnbitcom4 HN recommenders · 2021–2025
191K views · talk · evergreen · Uploaded 2015-11-11
Rob Pike's Go talk distinguishing concurrency, the structuring of independent processes, from parallelism, their simultaneous execution. It uses Go channels and goroutines to illustrate.
The standard link for explaining the concurrency versus parallelism distinction and the motivations behind Go's concurrency model.
38:47RailsConf 2014 - All the Little Things by Sandi Metz
Confreaks
1:01:39"Simple Made Easy" - Rich Hickey (2011)
Strange Loop Conference
25:06"Making Impossible States Impossible" by Richard Feldman
elm-conf
1:12:27CppCon 2015: Andrei Alexandrescu “std::allocator...”
CppCon
51:18Lexical Scanning in Go - Rob Pike
GoogleFOSSSydney
1:00:19How To Design A Good API and Why it Matters
Google TechTalks
31:44The Value of Values with Rich Hickey
InfoQ
1:04:04Overwatch Gameplay Architecture and Netcode
GDC Festival of Gaming
6 comments from Hacker News
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): [VIDEO]
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] [VIDEO] "Concurrency is not Parallelism" talk by Rob Pike.
Anyone that can wrap their mind around the model of Communicating Sequential Processes[1] implemented using channels in Go will improve their programming. See also Concurrency is not Parallelism by Rob Pike: [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]
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 [VIDEO] )
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 [VIDEO]
Agreed. Rob Pike presented a good talk "Concurrency is not Parallelism" which explains the motivations behind Go's concurrency model: [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.