To a certain (high) degree I agree. First of all, when I'm wrote this article by coroutines I meant specifically Python async/await pattern which I don't find

To a certain (high) degree I agree. First of all, when I'm wrote this article by coroutines I meant specifically Python async/await pattern which I don't find easy to use or read. And I agree on Tornado. Over the years I've seen many APIs that abstract away stuff like implementation details of cooperation yet are in fact coroutines - e.g. goroutines in Go, tasklets in Stackless. Even Erlangs processes are, on the VM level, cooperatively scheduled green threads. For me there are 3 problems when you design concurrency APIs. One is performance and language internals. Second is API that you expose to the end programmer. Third problem is what you can achieve as a programmer using those API based on how integrated concurrency is into the language. All the examples of higher level platforms I know are good for highly concurrent apps: Erlang, Go, Node.js, GCD - they were designed and throughly integrated into the language. In that context threading in Python really feels bolted on. And for something different: seeing how some people reacted I'm diving deep to make 2-3 articles of tour-de-concurrency. What do you think?