Seems java's virtual thread is the only sane async model out there.
Rust chose a different path that is not more complex, but the complexity lies elsewhere.
For instance, there are many system-level data structures that are not allowed to migrate from one thread to another (e.g. Linux mutexes or Rust's Rc) or sometimes from one core to another. If you adopt uncolored async (unless perhaps you're using a thread-per-core scheduler), you just can't manipulate these data structures. At all.
Which means that you can't be a system programming language (for some definition of system programming).
By the way, if you wish to test uncolored async in Rust, you can find an implementation here: https://github.com/Xudong-Huang/may .
You don't want to use blocking mutexes anyway with async.
> or Rust's Rc
This is only half true. The danger is that two `Rc` that point to the same data are in different threads. But it should be safe to move all of them at once from one thread to another, which is exactly the case if all the `Rc`s involved live inside a `Future`. The problem is that this is a non-local property that's hard to encode in the type system.
> By the way, if you wish to test uncolored async in Rust, you can find an implementation here: https://github.com/Xudong-Huang/may .
FYI that's known to be unsound due to thread locals. And more generally it doesn't seem to give much attention to safety (see for example how it allowed unsound scoped tasks, or the fact it allows doing unsafe operations in some of its macros due to wrong scoping of `unsafe` blocks).
A simple call to https://pkg.go.dev/runtime#LockOSThread solves that.
Pay the cost of backwards compat when you need it, don't pay it when you don't need it.
I never understood the fascination for working with cutting edge languages; to me it just increases the likelihood that you're going to find language errors or library errors and get tied up for ages helping to refine the environment. Plus the relatively small size of the developer community and supporting literature available.
Maybe it's a dog people thing, the sort of people that get into it are the sort of people that want to go home and have a dog with infinite energy bouncing up and down all the time.
Just exhausting to even think about.
But I'm always thinking that the JVM is a pretty solid platform that has not yet reached its full potential. It gets a bad rap because of the hellhole that enterprise software is. But come on, look at android, look at games like Minecraft. Solid projects, written in large part in Java.
And people write mods for it and have had success. If that is not solid what is. For real what's so bad about minecraft, it even runs on a relatively old laptop of mine with 8 gigs of RAM without any lag.
In most safety software you can't even use dynamic memory. Maybe a lot of the software we write in that domain would be considered "bloat" in others, but I don't know what are the constraints that Minecraft faces that drove it to be implemented the way it is. But despite the bloat, they managed to do a lot.
When Minecraft came out, 8G of RAM would be pretty much the highest-end system you can buy. It's really not the flex you think it is.
In terms of the opposite direction from Minecraft in stability is Factorio, which can easily run on a multiplayer server for a gaming group on a potato of a computer and whose high-end multiplayer record is well over 500.
Whatever about anything else, Rust has definitely moved past "cutting edge"