Posting on behalf of @saeta and @compnerd (and on my own behalf of course).
Some of the systems programming folks we've been talking with would dispute whether that is good. They point out that, aside from having lower absolute performance costs than queues, in a lock-based system there are proven tools for deadlock detection and debugging. [^1]
While we think an async/await system is probably essential for Swift, we are also concerned that this proposal may be ignoring the foundations that proven concurrent programming is built upon. By starting from the middle (e.g. without updating the memory and ownership models), choices incompatible with systems programming may be baked into the language.
Most of all—and this is difficult because we do appreciate the obvious effort that has gone into these proposals on behalf of the whole Swift community—a massive document set is being exposed for the first time, with very little prior opportunity to discuss the approach here in the forums. That makes it something of a fait accompli, which nobody can reasonably challenge at a fundamental level without implying a huge cost to the proposers.
[1] Incidentally we don’t understand the claim being made that deadlocks are eliminated, since as far as we know, two actors can easily wait on one another’s results.