> But I also don't buy into the argument that implementing such foundational primitives like control flow in library code is good (I use async Rust every day, and it sucks how much has been pawned off to the ecosystem, please don't reply to this comment telling me how wrong I am). Even if you can implement these things in the ecosystem doesn't mean you should - it leads to bifurcations in the wild where libraries become incompatible because they aren't working with the same tools. The very thing that makes programming a force multiplier is modularity and reuse, making those harder by making a language too expressive makes that language worse, imo.
That seems pretty backwards to me. Being able to implement flow control as regular functions increases modularity and reuse a lot, not least because it makes it easy to abstract across async or not. IMO the biggest reason async Rust is so painful is precisely because control flow is a bunch of special case magic builtins that you can't share or reuse (e.g. you can't use regular if/while/for with async, and you can't write your own equivalents (like Haskell's ifM/whileM) because the language doesn't provide the tools you'd need to do that).
Sorry, yes, what I meant was you can use builtin if/while/for, but they're magic special cases that you can't reuse. E.g. if you have a repeated snippet of code that uses if/while/for, you might have exactly the same code in one async and one regular function, but you can't factor it out into a shared helper function (you can write the async and the non-async version of that helper function, but you can't write one that does both).
I believe the distinction is that in rust, `if a_cond.await` can only be written in an async function, whereas Haskell’s `ifM` takes a `Monad Bool` (and async is a kind of monad) as its condition and therefore can be written anywhere, not just within an existing monad.
That's a distinction without a difference. `ifM` takes a monadic bool but it also returns a monadic value, in exactly the same way that `.await` can only be done within an async computation.
That seems pretty backwards to me. Being able to implement flow control as regular functions increases modularity and reuse a lot, not least because it makes it easy to abstract across async or not. IMO the biggest reason async Rust is so painful is precisely because control flow is a bunch of special case magic builtins that you can't share or reuse (e.g. you can't use regular if/while/for with async, and you can't write your own equivalents (like Haskell's ifM/whileM) because the language doesn't provide the tools you'd need to do that).