> Does it come down to fundamental language differences?

No, I don't think there's anything fundamentally different.

Ruby 3.0 implements a "fiber scheduler" feature that enables "colorless Async". Fiber scheduler is an obscure Ruby feature, but the end result is brilliant. It was also a huge amount of work.

Side note: Fiber scheduler was implemented by the same guy who created Async Ruby - Samuel Williams. This guy is the mastermind (and master-coder) behind this project.

> Does anyone have any insight into why Python async doesn't work the same way?

Ruby async seems to be implemented using stackful coroutines. IIRC Guido has been opposed to adding these to core Python, preferring stack-less coroutines because they require every yield-point to be explicit (i.e. marked with `await`).

There are libraries for a python that support stackful coroutines, such as gevent.

I'm optimistic that this will be less painful as more of the Python ecosystem becomes async-friendly. We have `aiohttp` as a suitable replacement for `requests`, and major libraries like Django (not ORM yet), Flask, FastAPI, SQLAlchemy now have async support as well.

It has already gotten less painful as time goes on. However, in my experience so far if I need e.g. Django to use Google Cloud Storage for media storage, I need to write my own shims that marry together an async alternative to Google's Python SDK (which I have no idea if there are any plans for async support) with third part django packages that I'd normally use. The experience isn't terrible, but I end up spending a lot of time trying to making consistent calling conventions.

And I think I've come to the conclusion that any re-usable code I write for IO should just be written async with magic sync wrappers for use in sync contexts.