Hacker News Reader

Concurrency does not equal parallelism.

Lets say there's one core, or "hardware thread". Then the scheduler has no choice but to stick them all on the same thread. They are running concurrently but not in parallel.

With more cores, Go can schedule them to run in parallel.

Rob Pike has a great talk on YouTube titled something like "Concurrency is not parallelism" on this exact thing.

Indeed, taken from "Go Proverbs" - https://go-proverbs.github.io/

"Concurrency is not parallelism."

> Video: https://www.youtube.com/watch?v=PAAkCSZUG1c&t=3m42s

The way all of this works is nicely detailed here: https://rakyll.org/scheduler/

Yup, and in fact, Go will try its best to keep ownership of a single (hardware) thread, spinning no-ops on it to avoid a context switch in some situation. (or something to that effect)