Their terminology is concurrent programming. So you never actually spawn threads. But just declare your code to be able to run concurrently. So it will parallel process on multi cpu machine. Or just get scheduled in/out of cpu, when waiting for I/O. So very much like threads, but the mental/programming model is different.

Channels are particularly very useful, where you would use a thing like Barrier in Java, for threads to converge. In channels you get concurrency by message passing on channels.

So example application can be, crawl multiple sites concurrently and converge using channels.

In my experience its very robust, and once coded and tested, rarely(if at all) you face any weird bugs, e.g. Deadlocks/etc which you would, in explicit threaded programming. Not to imply that its not shoot-in-the-foot proof. But for a programmer having experience of multi-threaded programming, when one moves to this model, it seems more intuitive and robust.

Edit: I see other programmers have endorsed http://tour.golang.org/welcome/1 . I second/third them. IMHO that's the best resource to learn Go (and from your browser). After I did the 70 or thereabouts exercises, over there, I attained Nirvana :-) , and didn't need anything else. Of course apart from golang pkg docs. And one piece which confused me in the beginning was slice/array. Its very easy, once you get a hang of it. Another thumb rule I follow is always have pointers to struct in slices or maps. To avoid, the costly copy. May be its obvious in hindsight, but wasn't to me, in the beginning, as sometimes passed pointer to slice, having struct as values, to a function argument. On realizing what a foolish thing it was, as slice/maps are passed by reference, I started doing the reverse (i.e. slice as is, but having pointers to structs) :-).