What? No it isn't. Go's concurrency support is fundamentally different than Python's idiomatic approach (event libraries). It's an apples/oranges comparison. If one approach is more performant than the other, I'd bet on the event library, since evented programs are more or less scheduled purely by I/O.
I like Go. I've been writing in it for a couple of weeks now and will continue to. But don't oversell it.
I'm pretty sure i/o bound go routines will use the very same kernel eventing mechanism. I looked into this recently, and you have to explicitly tell it to use more than one thread with http://golang.org/pkg/runtime/#GOMAXPROCS
It certainly is. Just look at the insanity of the nonblocking I/O experience in Python. It's confusing, divided, and results in duplicated work all the way down to the database driver level.
I'm not overselling it. I'm someone who's built an entire web framework around gevent and knows that having this functionality in the library is a massive weakness of Python.
In Python, we have monkey patching vs. an entirely new driver vs. just using blocking calls.
In Go, we just have nonblocking I/O because that's how it works.
In both goroutines and events, blocking IO will be parked waiting on a select (or similar device). In both, they implicitly context switch while blocking, meaning that processing ready IO might have to wait for other stuff to reach a scheduling point. Unlike events, goroutines can be processed on more than one underlying OS thread at once.
I like Go. I've been writing in it for a couple of weeks now and will continue to. But don't oversell it.