3 ms·

> It would be better if you didn't have to label it and it all Just Worked However, this is not possible. When you have concurrent code, whether you make it ob

by dwaite 5y ago

> It would be better if you didn't have to label it and it all Just Worked However, this is not possible. When you have concurrent code, whether you make it obvious or hide it, you have contention over any shared mutable state. async/await is meant to have the pieces with contention be cooperatively multitasked, and the yielding of control is explicit so that you can understand that the state going into the call may be different than the state once you come out - any number of unrelated things may have run in between when you awaited and when control returned. Not having coloring means that you have turned an explicit cooperative system to an implicit or even preemptive system. There are definite advantages and disadvantages to both, with the difficulty in tracking down and debugging concurrency issues in implicit/premptive systems being the reason that there has been so much research into other approaches such as async/await, actors, and structured concurrency.

jerf 5y ago
Contention over mutable state is orthogonal to async/await in Rust. Proof is that they had the contention problem solved prior to async/await. Pure functional languages also solve the contention problem by simply destroying mutable state, without async labelling. A brute force solution, but a solution. async/await doesn't solve the problem of things possibly mutating things when you weren't running; you've turned over the thread of control, if your language permits mutation it can happen without you knowing. Rust solves that in other ways that have nothing to do with async/await, and its solution works with preemptive threading. Rust has been able to thread since long before async/await was introduced. It was introduced because for some of the use cases of Rust the overhead was unacceptable, not because prior to async you had no options at all to have that sort of functionality.
- gpderetta 5y ago
  Couldn't agree more with everything you have written.

by dwaite 5y ago

jerf 5y ago

Contention over mutable state is orthogonal to async/await in Rust. Proof is that they had the contention problem solved prior to async/await. Pure functional languages also solve the contention problem by simply destroying mutable state, without async labelling. A brute force solution, but a solution. async/await doesn't solve the problem of things possibly mutating things when you weren't running; you've turned over the thread of control, if your language permits mutation it can happen without you knowing. Rust solves that in other ways that have nothing to do with async/await, and its solution works with preemptive threading. Rust has been able to thread since long before async/await was introduced. It was introduced because for some of the use cases of Rust the overhead was unacceptable, not because prior to async you had no options at all to have that sort of functionality.

gpderetta 5y ago
Couldn't agree more with everything you have written.