Concurrency in Swift: One possible approach
I&#x27;m surprised that async&#x2F;await is the preferred idiom.<p>Having worked with async&#x2F;await in Node.js a lot, it is of course a significantly better solution than plain promises, but it is also quite invasive; in my experience, <i>most</i> async code is invoked with &quot;await&quot;. It&#x27;s rare to actually need to handle it as a promise; the two main use cases where you want to handle the promise as a promise is either when doing something like a parallel map, or when you need to deal with old callback-style code where an explicit promise needs to be created because the resolve&#x2F;reject functions must be invoked as a result of an event or callback.<p>Would it not be better to invert this -- which is the route Erlang and Go went -- and make it explicit when you&#x27;re spawning something async where you don&#x27;t want to deal with the result right away? In Go, you just use the &quot;go&quot; keyword to make something async. So the caller decides what&#x27;s async, not the callee. If callers arbitrarily decide whether to be async or not, a single async call ends up infecting the whole call chain (which need to be marked &quot;async&quot; unless you&#x27;re explicitly handling the promise&#x2F;continuation without &quot;await&quot;).