Python struggles with it because so much networking code deep in networking libraries such as gunicorn, database libraries like psycopg, depend (or did depend) upon mutable global state and non-reentrant blocks of code that, upon introducing concurrency result in all a manner of poor behavior.

Do a search for "psycopg2 decryption failed or bad record mac" for example. Or replace psycopg2 with celery, or gunicorn. Python has a difficult history of half-way attempts to parallelize, a half dozen eventlet libraries that never made it to the standard, and only recently - in terms of library support - is an official coroutine implementation available, albeit not as widely used as it needs to be. Library support is still widely lacking.

It's not that Python can't do it well, it's that the ecosystem has dug themselves a pit by doing things that aren't legal Rust and would be frowned upon in other languages. Those hacks to support parallelism and greenlets, gevent, etc. rely upon juggling file descriptors and carefully tweaking global state in each library. It's gnarly stuff and results in errors that are clearly the result of failing to catch all the balls correctly.

Those SSL errors, by the way, are incredibly concerning. It means that wires are getting crossed and if it weren't for SSL authenticating the packets, the wrong data would happily get sent or received to the wrong party. In a network server, yikes.

Well that isn't entirely true. Java is doing it in a similar way to Go in that every call to I/O or other function that would block can suspend the current virtual thread. But if it's called in a standard blocking thread then it blocks as expected (in Java w/Loom that is, ofc every goroutine is a green thread). This is of course a ton easier in Java and Go because of the managed memory model.

However I would be interested in hearing what the specific Rust features (or lack thereof) that prevent this being possible. If it's possible to swap the async runtime out it seems like it should also be possible to add enough runtime to a Rust program to allow the equivalent of virtual threads as long as stuff uses stdlib sockets, file I/O etc.

You are welcome to propose a better method