Actually the most interesting part of the article is not about using GOMAXPROCS, but exactly how using GOMAXPROCS doesn't automagically turn your program into a parallel one: only a real analysis (helped with the helful profiler) tells you whether you've achieved true parallelism. The author's program wasn't truly parallel until he saw the bottleneck with the global mutex lock.

Said differently: concurrency is easy ("just" go func() all the things), parallelism is hard (GOMAXPROCS is not enough, you'll have to go deeper)

Yup, here's what I normally use for these situations (posted it in disqus too at end of article):

// Initialize to use all available CPU cores

func init() {

   runtime.GOMAXPROCS(runtime.NumCPU())

}

Maybe GOMAXPROCS exists so that the number of hw threads that might be spawn by the go application can be controlled in a more system-agnostic way. Without such env varianle, on Windows (for example) you can control this with CPU affinity (and possibly other better ways), but not sure about Linux/OSX/etc. So this kind of deals with it upfront.