They should let this author commit changes to the runtime package docs, because this explanation of GOMAXPROCS is much more clear than the official docs.

This article: "the number of CPUs (whatever your operating system considers to be a CPU) visible to the program at startup."

Official docs: "The number of logical CPUs on the local machine can be queried with NumCPU." and "NumCPU returns the number of logical CPUs usable by the current process."

The problem with the official docs is they don't mention that the value of NumCPU is locked in at startup and never changes.

The fact that it's locked in at startup might be an implementation detail that they don't want people generally relying on, but I personally don't know if that's the case.

That may be, but the docs for NumCPU are still just wrong. NumCPU does not return the number of logical processors in the machine. It returns the population count of the cpu mask, at the moment the runtime was initialized.

He is part of the Go team.

Dave is a very prolific and important contributor, but he is not on the Go team.

Splitting hairs; as you say he is a prolific contributor.

Site's down for me.

http://webcache.googleusercontent.com/search?q=cache:OXupz2Z...

Maybe he should use Go instead of PHP.

As a strong proponent of both, I'd say PHP is the better fit for a small blog.

There's also GO15VENDOREXPERIMENT in Go 1.5. It enables dependency vendoring with a vendor/ directory for each package.

More details here: https://golang.org/s/go15vendor.

I'm using this now. Looks like they will be releasing an official vendoring mechanism for 1.6. https://blog.golang.org/6years

Yes, but it's not a variable for the runtime.