💾 Archived View for dcreager.net › languages › rust › let-futures-be-futures.gmi captured on 2024-06-16 at 12:14:32. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2024-03-21)
➡️ Next capture (2024-08-18)
-=-=-=-=-=-=-
2024-02-13
This is a good post about Rust's futures/async mechanism:
Let futures be futures [without.boats]
It's less antagonistic towards Nystrom's “colored functions” argument, even though the author doesn't agree with it.
As I was reading this, I kept thinking that some of the proposed benefits aren't limited to futures (you can compose functions just fine) and that I still think there's a benefit to something based on futures/async as an underlying implementation without having to expose that at the language level. But they cover those objections in the “digression about coroutines” at the end! That led me to this fantastic quote about how async/await is where you tend to land when you need C ABI compatibility:
Async style language features are a compromise between your execution model being natively compatible with the 1:1 C ABI, C standard library, and C runtime and a M:N execution model...The cost for the native compatibility with the C/system runtime is the “function coloring” problem.
which in turn led me to [deMoura2009], which describes the alternative “stackful” coroutine model (which Lua uses) in more detail.