3 ms·

What are the major issues with this concept? I often wonder why async isn't the standard and we have to manually decide to use it (what if a function we thought

What are the major issues with this concept? I often wonder why async isn't the standard and we have to manually decide to use it (what if a function we thought would be fast actually takes long?). Considering that it seems to be a "best practice" to use async functions whenever remotely required, it would be bad developer experience (and lead to unwanted results) to make people do extra work to use it.

recursivedoubts 5y ago
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
KingOfCoders 5y ago
I'm also thinking about a language where async is default. https://hirolang.org/ 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.
int_19h 5y ago
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.

recursivedoubts 5y ago

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

KingOfCoders 5y ago

I'm also thinking about a language where async is default. https://hirolang.org/ 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.

int_19h 5y ago

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.