to be honest, I've used both gevent and Go and concurrency is far more natural in Go. Sure, you can do most of what you want with gevent, and if you're using stackless or pypy you can even have channels, but implementing concurrency at the library level is a mistake. It feels bolted on. It's like how some programming languages weren't object oriented from the start, but then they bolted an object system on top of it in a later release; it feels kludgy and you notice that it's bolted on. Concurrency in Python reminds me of that. Yes, it works, but it's awkward and feels like a second-class citizen.
I've done concurrent programming in both Python and Go, and to be fair to Python, its standard library queue class (http://docs.python.org/library/queue.html) is very close to Go's channels so it does CSP style concurrency quite nicely.
However, Go's goroutines are IMHO superior to Python threads since they're much more lightweight and can run in parallel on multi-core CPUs and you can have a lot more of them.
Go gets it right by putting goroutines and channels into the core language to encourage CSP style concurrency, but putting other more traditional, but harder-to-use, concurrency primitives like mutexes into the standard library.
