Would you be willing to explain why explicit asynchrony is superior to implicit cooperative threading? Rather than simply engaging in more namecalling.
Mutable state is always a problem, but it's a bigger problem when there are less constraints on when it can mutate. But Mark's dissertation explains this and some related issues a lot better.
>Mutable state is always a problem, but it's a bigger problem when there are less constraints on when it can mutate.
A very long-time project I’m idly working on with my life-long colleague addresses this issue. It is real, as are all race conditions and threading issues. But it doesn’t have to be solved at the language level.
One of solutions we proposed to ourselves was that an object storage should manage shared access conflicts. You may see it in Redux and other stores that serve a “frontend framework backend layer” duty today. Even with explicit async, you will always have some high-level races that must be dealt with. And these do exactly that.
The basic idea is that local state is strictly local and not a subject of parallel mutation, and shared state is shared via internally locking/serializing controller who knows better how to mutate, merge or throw. It doesn’t push the problem down the code or execution model, since it’s what’s it for.
That isn't a "normative" statement about better, but a "positive" statement about a trade-off of expressive power versus rigor. A bit of mathematical intuition suggests that formally asynchronous approaches tend to be less powerful and hence more rigorous. But if your spec is still in the prototype phase, taking on a lot of expressiveness and permission with respect to your domain model is desirable because it gets you an end-to-end solution sooner.
What is good is not "on time" or "robust", but "on time and robust". Necessary and sufficients.
kragen|6 years ago
Also, I don't think I did any name-calling?
wruza|6 years ago
A very long-time project I’m idly working on with my life-long colleague addresses this issue. It is real, as are all race conditions and threading issues. But it doesn’t have to be solved at the language level.
One of solutions we proposed to ourselves was that an object storage should manage shared access conflicts. You may see it in Redux and other stores that serve a “frontend framework backend layer” duty today. Even with explicit async, you will always have some high-level races that must be dealt with. And these do exactly that.
The basic idea is that local state is strictly local and not a subject of parallel mutation, and shared state is shared via internally locking/serializing controller who knows better how to mutate, merge or throw. It doesn’t push the problem down the code or execution model, since it’s what’s it for.
beetwenty|6 years ago
What is good is not "on time" or "robust", but "on time and robust". Necessary and sufficients.