I’m not sure if this is a better place to post or on the other Rust thread, but I’ve been diving into Trio, loving it, and resurrecting some old conversations I had about Rust concurrency over on the RFCs repo a long time ago. The discussion is here, somewhere in the middle of the thread, but I don’t necessarily think its a terribly interesting read.
What came of that conversation was the suggestion, which seemed roughly reasonable at the time and even now, that in a language like Rust, with its emphasis on memory safety and ownership, that while same-thread concurrency is valuable, that splitting the world into colored functions may not be the right way to do it for Rust, though I do not think I had, or have, a solid answer on what I think would be best, all things considered.
Trio has some absolutely awesome primitives, especially nurseries and the like, that would be awesome for Rust, and I’m having a blast learning about Trio, reading through this forum, and following discussions on these design decisions.
What I’m wondering is, especially given the attention paid to ownership and thread-safety in Rust, is there significant extra value that explicit async and await give in that context, especially given the overhead of splitting the world of functions? The cost of splitting the world of functions seems like an absolutely huge cost, and I’m having trouble identifying where it would be a huge help to dealing with things over using implicit concurrency with green threads, given how much care has been taken to make multithreading as safe as possible in Rust.
In Python multithreading is a huge, difficult issue, and using explicit async/await really helps make that more manageable. Are there significant enough issues that, even with the excellent ownership system of Rust, are still present to warrant such a split of the world?