> Go shares most of those downsides
Does it? Preemptability is pretty robustly solved in Go. While it's sometimes less efficient than I'd like, it's a far cry from the initial draft of virtual threads in java where a misplaced "synchronized" could sneakily starve entire executors. Even with CGo pinning (which, as you indicate, is rare due to the bulk of pure-Go libraries) I'm having trouble thinking of reasonable situations where full starvation or deadlock occurs rather than (admittedly unpleasant!) latency and queueing.
That said, Loom is quite new and deliberately iterative in approach, and the Java core folks are quite skilled, so I do expect to see substantial improvements in behavior and issue-detection tooling here over the coming years.
> I'd consider all three implementations of the approach to be dead on arrival
I'd argue that eventlet/greenlet failed for different reasons than the concurrency model or starvation risk (the monkeypatching approach just can't sustainably work in an ecosystem as big and native-code-dependent as Python's), hence Python's falling back to traditional async/await cooperative concurrency.
The Rust folks are struggling with the same choices here as well, further constrained by their requirements of a GC-less runtime with near-zero-overhead C FFI, which precludes them from using Go's approach. There was some great discussion of that here: https://news.ycombinator.com/item?id=39242962
