[enneff]

PyPy is an amazing project, but it is my understanding that the Python language makes certain guarantees (particularly around thread safety) that will hamper the speed of any implementation for a long time.

Go is still really young, yet it's plenty fast. There's plenty of room for it to get much faster.

[ootachi]

You don't say exactly what you're referring to, but I assume it's the GIL. The GIL exists because Python threads share a single global namespace, and synchronizing atomically on hash tables for module lookup would be way too slow. If you create isolated contexts (like goroutines, but without shared state), the GIL won't bite you (edit: the degenerate cases that folks like David Beazley has described notwithstanding, but those aren't part of the language semantics and have more to do with unfortunate edge cases arising from the way Python's runtime interacts with the OS scheduler).

The problems with making Python fast mostly have to do with its complicated semantics, particularly around things like name lookup; the GIL doesn't have much to do with it.

Interestingly, I predict Go will have a much tougher time here, unless a form of goroutine is created that can't share any state at all. PyPy has been able to do a lot of garbage collection work precisely because it doesn't have to do concurrent GC. Unfortunately, Go crossed that bridge and can't really go back at this point.