See " How goroutines work. "
They are cheaper in:
- memory consumption:
A stream starts with a lot of memory, not a few Kb. - Installation and Stall Costs
(This is why you should maintain a thread pool) - Switching costs
Streams are scheduled in advance, and during thread switching, the scheduler must save / restore ALL registers.
Unlike Go, where runtime controls the goroutines from creation to planning to frustration. And the number of registers to save is lower.
Plus, as mentioned in Gos march to the low-latency GC , GC is easier to implement when the larynx control execution time is executed:
Starting with the introduction of its parallel GC in Go 1.5, the runtime keeps track of whether goroutine has been running since the last scan of its stack. The label completion phase would check each goroutine to see if it was recently launched, and rescan several of them.
In Go 1.7, the runtime maintains a separate short list of such goroutines. This eliminates the need to view the entire goroutines list while the user code is paused, and significantly reduces the number of memory accesses that can trigger the memory migration code associated with NUMA kernels.