I think async/await is semantically similar to the promises pattern [1] but different to the Go concurrent models using channels. What the compiler does with await/async is quite interesting [2]. Essentially it takes your await/async code and turns the related code into a state machine which keeps track of how control should be switched between the callee and the await keyword (and uses Task for the async bit).

[1] http://blog.parse.com/2013/01/29/whats-so-great-about-javasc...

[2] http://www.codeproject.com/Articles/535635/Async-Await-and-t...

Thanks for replying.

But I'm not trying to say that async/await are superior to the actor paradigm (which is what my understanding Go subroutine, don't call em threads things are).

Just that I would have hazarded a guess for pinging a bunch of servers, the TPL stuff is a better choice, than actor?

I feel there is a lot of buzz around Go, though I'm not seeing why. I guess my only option is to find something suitable enough for it, and give it whirl. But of course I am lazy, so trying to find someone elses suitable experiences would be great.

This is a good overview of Go concurrency:

http://www.slideshare.net/jgrahamc/go-oncurrency

As a Java developer I personally don't find it that impressive compared to something like the LMAX Disruptor or even Vert.x but I can appreciate that it is simple and that always counts for a lot.

As an Ada 95 developer, I like that Go seems to have an Adalite concurrency-related syntax.

Both systems have a CSP design, right? Golang is pretty up front about having lifted its design from Hoare.

Yes, you're right - the design comes from CSP. The syntax looks nicely Adalike.