Either way I'm excited to be able to generalize over asyncness.
*EDIT*: I now see that they explicitly address this question in the post:
> The short answer is: kind of, but not really. "Effect systems" or "algebraic effect systems" generally have a lot of surface area. A common example of what effects allow you to do is implement your own try/catch mechanism. What we're working on is intentionally limited to built-in keywords only, and wouldn't allow you to implement anything like that at all.
> What we do share with effect systems is that we're integrating modifier keywords more directly into the type system. Modifier keywords like async are often referred to as "effects", so being able to be conditional over them in composable ways effectively gives us an "effect algebra". But that's very different from "generalized effect systems" in other languages.
I’m not a fan. Async is a superset of sync and it would be much better long term if the overhead of an immediately fulfilled future could be optimized out by the compiler at compile time and be properly reflected by the type system without having to shoehorn this on from the outside.
I'm not sure whether I follow. Are you saying that basically everything should be async, but the compiler should just optimize that away when it's not "actually" async? Or did I misunderstand you.
Exactly. This is also necessary for the example code in the keyword generics proposal. You still need to write a .await and treat everything as being potentially async. Compare this to C++20s coroutine design where you practically have a zero overhead abstraction that might or might not be async without the author of the function having to necessarily know. They just yield control flow back to the caller who might suspend execution or not.
I’m not saying that one design is better than the other, just that this seems to be a bandaid on top of existing tradeoffs made in Rust’s async design that is only 2 years old.
4 comments
[ 2.5 ms ] story [ 17.2 ms ] threadEither way I'm excited to be able to generalize over asyncness.
*EDIT*: I now see that they explicitly address this question in the post:
> The short answer is: kind of, but not really. "Effect systems" or "algebraic effect systems" generally have a lot of surface area. A common example of what effects allow you to do is implement your own try/catch mechanism. What we're working on is intentionally limited to built-in keywords only, and wouldn't allow you to implement anything like that at all.
> What we do share with effect systems is that we're integrating modifier keywords more directly into the type system. Modifier keywords like async are often referred to as "effects", so being able to be conditional over them in composable ways effectively gives us an "effect algebra". But that's very different from "generalized effect systems" in other languages.
I’m not saying that one design is better than the other, just that this seems to be a bandaid on top of existing tradeoffs made in Rust’s async design that is only 2 years old.