This isn't a gotcha, it's an important aspect of how Go runs. While it's not highlighted enough concurrency isn't magic, and GOMAXPROCS is important to control your Go app, especially within production environments.
Although it's not well known benchmarks for programming languages would show even faster results for Go with GOMAXPROCS set to 1.
This lets single-threaded benchmarks run with less overhead.
A real missed opportunity in communication. Because this isn't the first time we see articles like these pop up.
It’s a containers / cgroups / linux problem. In the context of cgroups limiting CPU count usable within a given container, where an application in the container wants to ask the host kernel how many CPUs it can use, the application should have access to a system API that is informed by the cgroups configuration, but it doesn’t, at least not portably by default.
Although it's not well known benchmarks for programming languages would show even faster results for Go with GOMAXPROCS set to 1.
This lets single-threaded benchmarks run with less overhead.
A real missed opportunity in communication. Because this isn't the first time we see articles like these pop up.