Go's primitives are not really ideal for CPU parallelism. To make CPU parallelism nice you want things like parallel iteration constructs, which Go can't have because of lack of generics. Furthermore, any CPU parallelism work wants the best optimizer around and SIMD support to make best use of those cycles—otherwise it'd be better to just write in C++.

Goroutines and channels are best used as concurrency primitives, not parallelism tools.

Just to +1 this: it aligns with very nearly all Go-core-team concurrency/parallelism stances I've seen. Go intends to support concurrency, not parallelism, and they go to great lengths to remind people that they're not the same thing.

Who said anything about parallelism? Concurrency still works beautifully on multicore CPUs. I'm writing jobs that have lots of tasks, not jobs that parallelyze a single task...

Concurrency works just as beautifully on single-core CPUs. :)

yup, it works great on both :)