Asynchrony is not Concurrency

[m3makefile]

What do you think about this article?

https://kristoff.it/blog/asynchrony-is-not-concurrency/

lobste.rs thread:

https://lobste.rs/s/oeuohp/asynchrony_is_not_concurrency

[IsaacShelton]

Yes both the thread and article bring up good points. Async is far from a solved problem, definitely something to think about.

I haven't gotten that far in the design for this language yet, but having a (statically determined) contextual async runtime feels like the right direction I think.

There also has to be a way to express that very idea of things that have to run concurrently vs things that could be run concurrently if the async runtime supports it. (And abstract over the requirement to force things to run concurrently)

There is also another use-case I've been considering, which is the async executor pattern for mostly CPU bound tasks with ability to inspect which futures are deadlocked and custom CPU-driven wake conditions. Not sure what to do about this, since I don't think any language really has good support for this.

I would also like to know if it's even possible to have a good abstraction over all of these features:

• Stackful coroutines
• Stackless coroutines
• Prememptive or Non-Preemptive Async Runtimes (and how to these interact with Futures/Promises? + FFI)
• Ability to inspect aspects of the async runtime (would lose generality, but would gain power to monitor suspended tasks, etc.)
• Cold vs Hot futures
• Ability to cancel futures
• Pinned futures that don't require any allocation to be spawned
• Poll-based vs Push-based futures

and many other considerations that I'm probably forgetting at the moment

I'm delaying thinking too much about async right now since many other design areas have to be figured out first, but I do have an area carved out specifically for it later on, which should fit regardless of which abstraction we choose to do for async.

Specifically arbitrary compile-time code generation with a powerful module system really has a larger impact on the design than I initially expected since symbol resolution has to be completed unordered to stay sound (or have resolution depend on the lexical ordering of symbols which hurts parallelizability or have some symbols be second-class which hurts usage and still parallelizability), and how that will play out with async is another question.