Concurrency vs parallelism.
Interleaving tasks so nothing stalls, versus literally doing two at once — a skill versus a head-count.
Every morning you do concurrency without naming it: the kettle goes on, and while it boils you butter the toast. Nobody would claim you boiled and buttered simultaneously, with one pair of hands, yet nothing stood still — the kettle does not need watching. That is the whole concept: arrange tasks so the waiting overlaps.
Parallelism differs in kind, not degree. It means two things happening in the same instant, which requires two of something: hands, baristas, CPU cores. The pair get tangled because well-structured concurrent code is precisely what lets a runtime use extra cores — but one is how the work is arranged, and the other is how much hardware attacks it.
- All three of you: soon.1
Three customers were promised progress, and one pair of hands has to deliver it.
- Drip, you’re on your own.2
Every switch happens at a wait — the espresso drips just as well unsupervised.
- 3
Zoomed in, the truth shows: never two things in the same instant, never anyone abandoned for long.
- Together — pour.4
Here is the line switching can never cross — two pours in one instant takes a second barista.
- 5
Extra cores pay off only when there is computing to split; they do nothing for time spent waiting.
- You arrange; I assign.6
You write the interleaving; the runtime decides the head-count, spreading tasks over whatever cores exist.
Diagnose before you buy cores
Confusing the two wastes real money. A web server that is slow because every request waits on the database gains nothing from sixteen more cores — the cores it has are already idle; it needs better concurrency so the waits overlap. A video encoder pinning one core at 100% gains nothing from async restructuring; it needs parallel hardware. Watch where the time goes: waiting calls for structure, computing calls for silicon.
Write one, receive the other
The happiest division of labour is to describe the concurrency and let the runtime apply the parallelism. In Go you start goroutines and connect them with channels, never mentioning cores; the scheduler maps thousands of them onto however many cores the machine has, laptop or 64-core server, with the code unchanged. Java’s virtual threads and the async runtimes elsewhere make the same offer: concurrency is the program’s business, parallelism the machine’s.
Pairs well with Process vs thread
The real version How Go channels work →