effects-initiative

There is work happening on keyword generics[0], which would let a function be generic over keywords like `async` and `const`. For now the best option to write code that wants to live in both worlds is sans-io. Thomas Eizinger at Fireguard has written a good article about this[1] pattern. Not only does it nicely solve the sync/async issue, but it also makes testing easier and opens the door to techniques like DST[2] I have my own writing on the topic[3], which highlights that the problem is wider than just async vs sync due to different executors. 0: https://github.com/rust-lang/effects-initiative 1: https://www.firezone.dev/blog/sans-io 2: https://notes.eatonphil.com/2024-08-20-deterministic-simulat... 3: https://hugotunius.se/2024/03/08/on-async-rust.html

Cancellation isn't possible in general. For example, if you've kicked off expensive work on another thread or passed a pointer to your future to the kernel via io_uring, you must add a layer of indirection that's quite similar to a cancelation context. You can't just accept that the expensive work you don't care about will keep happening or resume a future that has been dropped when the cqe entry bearing a pointer to it arrives. The cancellation facility provided by io_uring that guarantees that you won't receive such a thing does so by blocking your thread for a while, which is undesirable. As implemented, async/await typically greatly harms composability. For example see here: https://nullderef.com/blog/rust-async-sync/ In the specific case of Rust, we might begin to be able to write composable libraries a couple decades from now: https

For those of you following along with keyword generics in Rust, the current proposal is this [0]: trait ?const ?async Read { ?const ?async fn read(&mut self, buf: &mut [u8]) -> Result<usize>; ?const ?async fn read_to_string(&mut self, buf: &mut String) -> Result<usize> { .. } } /// Read from a reader into a string. ?const ?async fn read_to_string(reader: &mut impl ?const ?async Read) -> io::Result<String> { let mut string = String::new(); reader.read_to_string(&mut string).await?; Ok(string) } which was rightfully disliked [1]. There have been some other proposals however, such as this one I wrote about [2] fn foo<F, T>(closure: F) -> Option<T> where F: FnMut(&T) -> bool, effect const if F: const, ?async, { /* ... */ } for which so