This brings back memories. Before Python had async/await, before asyncio became standard, I was happily writing concurrent code with gevent. I actually preferred it.

The reason was simple: no function color problem. With async/await, you split the world into two kinds of functions—ones that block by default and ones that don't. You have to mark the latter with async and remember to await them. With gevent, everything just blocks by default, and you spawn when you need concurrency. It's the same mental model as multithreading, just lighter. Project Loom in Java does something similar, though the technical details differ.

I sometimes wonder what Python would look like if it had embraced gevent-style coroutines in CPython instead of adding async/await. Or if Stackless Python had been accepted upstream. Maybe async programming would be more approachable today.

The explicit await keyword gives you visibility into where context switches can happen, sure. But in practice, I/O points are obvious even without the keyword—you're reading from a socket, querying a database, making an HTTP request. The explicitness doesn't really prevent race conditions or timing bugs. Meanwhile, function colors infect everything. One async library forces your entire call stack to be async. You end up maintaining both sync and async versions of the same code, or the ecosystem just splits in two.

With gevent, there's no such problem. You just call functions. Spawn them if you want concurrency, call them normally if you don't. Go's goroutines and Project Loom are popular for good reasons—they make concurrency accessible without the cognitive overhead.

Python's choice is history now, and there's no going back. But looking at how things turned out, I can't help but think the more practical path was right there, and we walked past it.