For the OP:
A thought to share on the general topic: Go is pioneering a sufficiently different model of concurrent computation that it may not make much sense to ask for or seek equivalencies with classic thread/process models.
This says nothing against the standard model, nor against the “missing” services; it is a note to encourage design in Go along with coding in Go, instead of design in C/C++/Java/POSIX/... and a best-effort realization in Go.
By way of analogy, I’ve long been involved in boat design and construction. We always use a pair Furuno or Simrad RADAR antennas, one of long range and one short, to optimize object detection/clutter rejection and as a redundancy safety factor. However, when sailing on a HobeeCat, i’ve never looked for nor missed the Radar or any other instruments of navigation. A HobieCat is just such a different idea of sailing that *all* the normal mechanisms have no place. There is no “where do I stow the anchor” or “where do I control the RAM signal lights.” There are whole chapters of the USCG instructions (ColRegs) where the thing discussed is not on a HobeeCat. That does not make such boats inadequate; it makes them fun.
If you can stop thinking of concurrency in Go as a small group of exquisitely instrumented machines and instead imagine a swarm of ants, you’ll find new and interesting ways to solve problems. They often work even better, and are also more fun.
--