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.

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

That's going to make data race conditions invisible, no?

How will developers cope with that?

To an extent yes, but consider the context: front end scripting

The javascript threading model is that there is a single thread executing so within a given bit of code you can be reasonably sure things are safe. The hyperscript runtime only allows one instance of a given event handler to execute at a time (unless otherwise specified) so the primary source of concurrency issues (the same code executing concurrently) is typically not an issue. By structuring your code such that it is on the same element (perhaps triggered by events elsewhere) you can effectively synchronize code in an intuitive manner.

I certainly wouldn't recommend the language for the back end though!

My team just spent three weeks hunting down a race condition in JavaScript integration tests. Turns out it was a missing `await`. So, I wouldn't claim that JavaScript is anywhere near safe :)

Admittedly, this was back-end, so it's possible that the situation is simpler in the front-end.

Good luck with your project!

Data races happen when there are multiple writers/readers of the same data. If one virtual thread of execution is multiplexed on several OS threads/workers/callbacks/you name it, there's still only one reader/writer at a time, because different parts of a multiplexed function don't run at the same time, they go one after another sequentially as before, with the difference is that there are now implicit continuation points where execution can hop from thread to thread (callback to callback). Can't say for hyperscript, but generally you need to protect your data with the same synchronization primitives as before, such as locks for example. It's only incompatible with thread locals and thread affinity, I'm not sure if JS has those.

If your data is composite (i.e. a JavaScript object or array) and you have several Promise-based flows of execution (technically not a virtual thread by most definitions of the term, but still a scheduled flow of execution) that end up reading/writing sub-parts of your piece of data in unpredictable order. That's basically a data race, in JavaScript. I've had to debug some of those.

As a side-note, some forms of data races (for perhaps a slightly looser definition of the term) can even happen without explicit asynchronicity, just with callbacks/synchronous events.