threads implementation specifics

[pazams]

Goroutines are lightweight threads (managed by Go, not OS threads).

Actually, the way goroutines are implemented are subject to the specific implementation. With gccgo, it does (or did?) use an OS thread for each goroutine.
from http://www.airs.com/blog/archives/448 :
"
On the functionality side, the gccgo library uses a single operating system thread for each goroutine. That is not what 6g/8g do: they multiplex goroutines onto operating system threads. Multiplexing is more efficient for a language like Go, and I need to change gccgo to work that way.
"

[a8m]

This sentence comes from Tour of Go. so, I prefer to leave it as it is.
However, it can be expanded based on your PR.

[pazams]

I'm not attached to this, so fine by me.
However, I would like to point out, the claim is supported by multiple sources:

• From the offical go spec:
  "
  The function value and parameters are evaluated as usual in the calling goroutine, but unlike with a regular call, program execution does not wait for the invoked function to complete.
  "
• Better worded in The Go Programming Language Phrasebook
  "
  A Go compiler may spawn a new operating system thread for every goroutine, or it may use a single thread and use timer signals to switch between them. The exact implementation mechanism for goroutines is not specified by the language and may change over time.
  "

Looks like a "tour of go" is more of a "tour of the current gc" ...

[pazams]

I'm changing my thought and closing this.
Though goroutines being "lightweight" is not part of the go spec, the fact that they are implemented as such is very important when choosing to use them.
It should stay mentioned here regardless of their spec status.