Concurrency vs parallelism.
One barista juggling many orders by switching between them, versus several baristas making drinks at the same instant.
These two words get muddled constantly, but they are different ideas. Concurrency is about structure: dealing with many tasks at once by interleaving them, even on a single worker who switches between them rapidly. One barista taking several orders, starting one, steaming milk for another while the first brews, looks like everything is progressing together — and it is, just not literally simultaneously.
Parallelism is about execution: actually doing multiple things at the very same instant, which needs multiple workers. Two baristas each making a drink at the same moment is parallelism. You can have concurrency without parallelism (one barista, many orders) and the two combine when you run concurrent tasks across several cores.
- Three orders, one of me.1
Concurrency is one barista with many orders — dealing with all of them at once.
- Brew that, froth this, back again.2
She starts one, steams milk for another while the first brews, switches between them fast.
- 3
Nothing happens at the same instant, yet everything keeps moving. That’s structure, not speed.
- On three — both pour!4
Parallelism is two baristas each pouring a drink at the very same moment.
- 5
That needs more hands. Add cores and CPU-heavy work genuinely finishes faster.
- You structure it; I’ll parallelise it.6
They combine: write concurrent tasks, and the runtime spreads them across cores for you.
Why the distinction matters
Concurrency shines when tasks spend time waiting — on the network, on disk, on a user. One thread can stay busy serving other tasks while one waits, with no extra cores needed; this is what the event loop and async code exploit. Parallelism shines when you have heavy computation to grind through and idle cores to throw at it: split the work and run the pieces literally at once. Mistaking one for the other leads to disappointment — adding cores will not speed up a program that is just waiting on I/O, and clever async will not make a single-core CPU crunch numbers any faster.
How languages give you both
Good tools let you write concurrent code that the runtime can then run in parallel when cores are available. Go is a clear example: you write lightweight goroutines and coordinate them with channels (a structured way to pass data between concurrent tasks), and the scheduler spreads those goroutines across the available CPU cores. You express the concurrency; the runtime decides how much actual parallelism to apply.