This post is primarily about Rust but the issues raised generalize to async models in any programming language. The tradeoffs between approaches are severe enough that it is desirable, at least in a systems language, to preserve enough flexibility that the model generalizes to different contexts without loss of performance or robustness. Furthermore, async tends to erode modularity in code because async behavior, which is tightly coupled to internal design choices, becomes part of the functional contract. There are all kinds of interesting edge cases around things like bounding worst-case resource pseudo-leakage that you simply don’t need to think about in synchronous code.
This is not to suggest that async models are a bad idea. They just have a higher level of intrinsic complexity and language support is immature. The benefit is qualitatively better scalability and performance, so there is a purpose behind using async models.
I liked the first sentence or two of your comment but I quickly stopped following.
Any concurrency model has tightly coupled & specific semantics about scheduling and cancellation: that's what a concurrency model is meant to provide. The semantics of "synchronous code" are just treated as natural by programmers because it's what they've been taught their whole lives, but someone had to invent that too (Edsger Dijkstra & Tony Hoare, specifically).
If all you mean to say is "the async model means whether a function synchronizes with a concurrent process becomes part of its contract", yes that's true, but the idea that this is "eroding modularity" and not "including essential facts about function behavior in its type signature" is an assertion of design principle, not a statement of fact.
Comments
This post is primarily about Rust but the issues raised generalize to async models in any programming language. The tradeoffs between approaches are severe enough that it is desirable, at least in a systems language, to preserve enough flexibility that the model generalizes to different contexts without loss of performance or robustness. Furthermore, async tends to erode modularity in code because async behavior, which is tightly coupled to internal design choices, becomes part of the functional contract. There are all kinds of interesting edge cases around things like bounding worst-case resource pseudo-leakage that you simply don’t need to think about in synchronous code.
This is not to suggest that async models are a bad idea. They just have a higher level of intrinsic complexity and language support is immature. The benefit is qualitatively better scalability and performance, so there is a purpose behind using async models.
I liked the first sentence or two of your comment but I quickly stopped following.
Any concurrency model has tightly coupled & specific semantics about scheduling and cancellation: that's what a concurrency model is meant to provide. The semantics of "synchronous code" are just treated as natural by programmers because it's what they've been taught their whole lives, but someone had to invent that too (Edsger Dijkstra & Tony Hoare, specifically).
If all you mean to say is "the async model means whether a function synchronizes with a concurrent process becomes part of its contract", yes that's true, but the idea that this is "eroding modularity" and not "including essential facts about function behavior in its type signature" is an assertion of design principle, not a statement of fact.