I'm also thinking about a language where async is default.

https://hirolang.org/

And what major issues and downsides this has. One I can identify it would be non obvious on how to do `map` on a Future/Promise, because there is none. So there is no easy way to execute on the green thread code with the result of the remote call, e.g.

   let f = asyncFuture()
   f.map(|v|: v + 1) // executes also async
   let s = await m
   println(s)

If f is transparently handled as a future, this is no longer possible, we would have:

   let s = asyncFuture()
   s = s + 1 // not async
   println(s)

One would also, to be safe, always use immutable data structure and copy semantics on other classes (e.g. functional lenses and prisms everywhere transparently) - with the performance impact of immutable data structures.

The issue is that the moment you cross the boundary into some other language (and note that this usually includes the APIs provided by the OS!), the caller and the callee have to agree on how green threads work.

It's not an issue with explicit async/await model, because that one desugars into callbacks, which can be described entirely in terms of the already-existing C ABI that is the baseline for FFI in any modern language.

i think it is because async came so much later in the life of javascript, and there are some pretty serious perf implications to do it completely transparently