The way those languages implement something that is uncolored is by making everything async. Rust has some other use-cases where that's not acceptable.

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.

It's not due to the memory model; it's due to the lack of a runtime. In Go/Java, virtual threads are provided by a runtime. Rust tries to stay close to the metal, and so has no runtime. It does not have virtual threads that could be suspended.

Rust used to have virtual threads pre-1.0, but they were removed since the overhead was deemed unacceptable.

Great! I would love that. However, having read the comments of the rust async working group, they think that async is the best thing since sliced bread ... They have no intention of changing IMO. Sigh. Hopefully one day we will get inclusive features rather than exclusive... Cheers

You are welcome to propose a better method

No I think I should put my money where by mouth is: I will take another route: asyncless rust should be simple enough to remove that part and make async/await compiler errors. Add this as a new target to rustup and we are good.