Dgdrxrt

What you are missing, is the purpose of async operations: They allow you to make use of your waiting time!

If you turn an async operation, like requesting some resource from a server, into a synchronous operation by implicitly and immediately waiting for the reply, your thread cannot do anything else with the waiting time. If the server takes 10 milliseconds to respond, there go about 30 million CPU cycles to the waste. The latency of the response becomes the execution time for the request.

The only reason why programmers invented async operations, is to hide the latency of inherently long-running tasks behind other useful computations. If you can fill the waiting time with useful work, that's CPU time saved. If you can't, well, nothing's lost by the operation being async.

So, I recommend to embrace the async operations that your languages provide to you. They are there to save you time.

Some do.

They're not mainstream (yet) because async is a relatively new feature that we've only just now gotten a good feel for if it's even a good feature, or how to present it to programmers in a way that is friendly/usable/expressive/etc. Existing async features are largely bolted onto existing languages, which require a little different design approach.

That said, it's not clearly a good idea to do everywhere. A common failing is doing async calls in a loop, effectively serializing their execution. Having asynchronous calls be implicit may obscure that sort of error. Also, if you support implicit coercion from a Task<T> (or your language's equivalent) to T, that can add a bit of complexity/cost to your typechecker and error reporting when it's unclear which of the two the programmer really wanted.

But those are not insurmountable problems. If you wanted to support that behavior you almost certainly could, though there would be trade-offs.

There are languages that do this. But, there is actually not much of a need, since it can be easily accomplished with existing language features.

As long as you have some way of expressing asynchrony, you can implement Futures or Promises purely as a library feature, you don't need any special language features. And as long as you have some of expressing Transparent Proxies, you can put the two features together and you have Transparent Futures.

For example, in Smalltalk and its descendants, an object can change its identity, it can literally "become" a different object (and in fact the method that does this is called Object>>become:).

Imagine a long-running computation that returns a Future<Int>. This Future<Int> has all the same methods as Int, except with different implementations. Future<Int>'s + method does not add another number and return the result, it returns a new Future<Int> which wraps the computation. And so on, and so forth. Methods that cannot sensibly be implemented by returning a Future<Int>, will instead automatically await the result, and then call self become: result., which will make the currently executing object (self, i.e. the Future<Int>) literally become the result object, i.e. from now on the object reference that used to be a Future<Int> is now an Int everywhere, completely transparent to the client.

No special asynchrony-related language features needed.

They do (well, most of them). The feature you're looking for is called threads.

Threads have their own problems however:

1. 
   

   Because the code can be suspended at any point, you can't ever assume that things won't change "by themselves". When programming with threads, you waste a lot of time thinking about how your program should deal with things changing.

   
   
   

   Imagine a game server is processing a player's attack on another player. Something like this:

   
   
   

   if (playerInMeleeRange(attacker, victim)) 
    const damage = calculateAttackDamage(attacker, victim);
    if (victim.health <= damage) 
   
    // attacker gets whatever the victim was carrying as loot
    const loot = victim.getInventoryItems();
    attacker.addInventoryItems(loot);
    victim.removeInventoryItems(loot);
   
    victim.sendMessage("$attacker hits you with a $attacker.currentWeapon and you die!");
    victim.setDead();
    else 
    victim.health -= damage;
    victim.sendMessage("$attacker hits you with a $attacker.currentWeapon!");
    
    attacker.markAsKiller();
   
   

   
   
   

   Three months later, a player discovers that by getting killed and logging off precisely when attacker.addInventoryItems is running, then victim.removeInventoryItems will fail, he can keep his items and the attacker also gets a copy of his items. He does this several times, creating a million tonnes of gold out of thin air and crashing the game's economy.

   
   
   

   Alternatively, the attacker can log out while the game is sending a message to the victim, and he won't get a "murderer" tag above his head, so his next victim won't run away from him.

   
   


2. 
   

   Because the code can be suspended at any point, you need to use locks everywhere when manipulating data structures. I gave an example above that has obvious consequences in a game, but it can be more subtle. Consider adding an item to the start of a linked list:

   
   
   

   newItem.nextItem = list.firstItem;
   list.firstItem = newItem;
   

   
   
   

   This isn't a problem if you say that threads can only be suspended when they're doing I/O, and not at any point. But I'm sure you can imagine a situation where there's an I/O operation - such as logging:

   
   
   

   for (player = playerList.firstItem; player != null; player = item.nextPlayer) 
    debugLog("$item.name is online, they get a gold star");
    // Oops! The player might've logged out while the log message was being written to disk, and now this will throw an exception and the remaining players won't get their gold stars.
    // Or the list might've been rearranged and some players might get two and some players might get none.
    player.addInventoryItem(InventoryItems.GoldStar);
   
   

   
   



3. Because the code can be suspended at any point, there could potentially be a lot of state to save. The system deals with this by giving each thread an entirely separate stack. But the stack is quite big, so you can't have more than about 2000 threads in a 32-bit program. Or you could reduce the stack size, at the risk of making it to small.

If I'm reading you right, you are asking for a synchronous programming model, but a high performance implementation. If that is correct then that is already available to us in the form of green threads or processes of e.g. Erlang or Haskell. So yes, it's an excellent idea, but the retrofitting to existing languages can't always be as smooth as you would like.

I appreciate the question, and find the majority of answers to be merely defensive of the status quo. In the spectrum of low- to high-level languages, we've been stuck in a rut for some time. The next higher level is clearly going to be a language that is less focused on syntax (the need for explicit keywords like await and async) and much more about intention. (Obvious credit to Charles Simonyi, but thinking of 2019 and the future.)

If I told a programmer, write some code that simply fetches a value from a database, you can safely assume I mean, "and BTW, don't hang the UI" and "don't introduce other considerations that mask hard to find bugs". Programmers of the future, with a next-generation of languages and tools, will certainly be able to write code that simply fetches a value in one line of code and goes from there.

The highest level language would be speaking English, and relying on competence of the task doer to know what you really want done. (Think the computer in Star Trek, or asking something of Alexa.) We're far from that, but inching closer, and my expectation is that the language/compiler could be more to generate robust, intentioned code without going so far as to needing AI.

On one hand, there are newer visual languages, like Scratch, that do this and aren't bogged down with all the syntactical technicalities. Certainly, there's a lot of behind-the-scenes work going on so the programmer doesn't have to worry about it. That said, I'm not writing business class software in Scratch, so, like you, I have the same expectation that it's time for mature programming languages to automatically manage the synchronous/asynchronous problem.

The problem you're describing is two-fold.

• The program you're writing should behave asynchronously as a whole when viewed from the outside.


• It should not be visible at the call site whether a function call potentially gives up control or not.

There are a couple of ways to achieve this, but they basically boil down to

1. having multiple threads (at some level of abstraction)


2. having multiple kinds of function at the language level, all of which are called like this foo(4, 7, bar, quux).

For (1), I'm lumping together forking and running multiple processes, spawning multiple kernel threads, and green thread implementations that schedule language-runtime level threads onto kernel threads. From the perspective of the problem, they are the same. In this world, no function ever gives up or loses control from the perspective of its thread. The thread itself sometimes doesn't have control and sometimes isn't running but you don't give up control of your own thread in this world. A system fitting this model may or may not have the ability to spawn new threads or join on existing threads. A system fitting this model may or may not have the ability to duplicate a thread like Unix's fork.

(2) is interesting. In order to do it justice we need to talk about introduction and elimination forms.

I'm going to show why implicit await cannot be added to a language like Javascript in a backwards-compatible way. The basic idea is that by exposing promises to the user and having a distinction between synchronous and asynchronous contexts, Javascript has leaked an implementation detail that prevents handling synchronous and asynchronous functions uniformly. There's also the fact that you can't await a promise outside of an async function body. These design choices are incompatible with "making asynchronousness invisible to the caller".

You can introduce a synchronous function using a lambda and eliminate it with a function call.

Synchronous function introduction:

((x) => return x + x;)

Synchronous function elimination:

f(4)

((x) => return x + x;)(4)

You can contrast this with asynchronous function introduction and elimination.

Asynchronous function introduction

(async (x) => return x + x;)

Asynchonrous function elimination (note: only valid inside an async function)

await (async (x) => return x + x;)(4)

The fundamental problem here is that an asynchronous function is also a synchronous function producing a promise object.

Here's an example of calling an asynchronous function synchronously in the node.js repl.

> (async (x) => return x + x;)(4)
Promise 8 

You can hypothetically have a language, even a dynamically typed one, where the difference between asynchronous and synchronous function calls is not visible at the call site and possibly is not visible at the definition site.

Taking a language like that and lowering it to Javascript is possible, you'd just have to effectively make all functions asynchronous.

In the case of Javascript, which you used in your question, there is an important point to be aware of: Javascript is single-threaded, and the order of execution is guaranteed as long as there are no async calls.

So if you have a sequence like yours:

const nbOfUsers = getNbOfUsers();

You are guaranteed that nothing else will be executed in the meantime. No need for locks or anything similar.

However, if getNbOfUsers is asynchronous, then:

const nbOfUsers = await getNbOfUsers();

means that while getNbOfUsers runs, execution yields, and other code may run in between. This may in turn require some locking to happen, depending on what you are doing.

So, it's a good idea to be aware when a call is asynchronous and when it isn't, as in some situation you will need to take additional precautions you wouldn't need to if the call was synchronous.

With Go language goroutines, and the Go language run time, you can write all code as if it was synchrone. If an operation blocks in one goroutine, execution continues in other goroutines. And with channels you can communicate easily between goroutines. This is often easier than callbacks like in Javascript or async/await in other languages. See for https://tour.golang.org/concurrency/1 for some examples and an explanation.

Furthermore, I have no personal experience with it, but I hear Erlang has similar facilities.

So, yes, there are programming languages Like Go and Erlang, which solve the syncronous/asynchronous problem, but unfortunately they are not very popular yet. As those languages grow in popularity, perhaps the facilities they provide will be implemented also in other languages.

There is a very important aspect that has not been raised yet: reentrancy. If you have any other code (ie.: event loop) that runs during the async call (and if you don't then why do you even need async?), then the code can affect the program state. You cannot hide the async calls from the caller because the caller may depend on parts of the program state to remain unaffected for the duration of his function call. Example:

function foo( obj ) 
 obj.x = 2;
 bar();
 log( "obj.x equals 2: " + obj.x );

If bar() is an async function then it may be possible for the obj.x to change during it's execution. This would be rather unexpected without any hint that bar is async and that effect is possible. The only alternative would be to suspect every possible function/method to be async and re-fetch and re-check any non-local state after each function call. This is prone to subtle bugs and may not even be possible at all if some of the non-local state is fetched via functions. Because of that, the programmer needs to be aware which of the functions have a potential of altering the program state in unexpected ways:

async function foo( obj ) 
 obj.x = 2;
 await bar();
 log( "obj.x equals 2: " + obj.x );

Now it is clearly visible that the bar() is an async function, and the correct way to handle it is to re-check the expected value of obj.x afterwards and deal with any changes that may have had occurred.

As already noted by other answers, pure functional languages like Haskell can escape that effect entirely by avoiding the need for any shared/global state at all. I do not have much experience with functional languages so I am probably biased against it, but I do not think lack of the global state is an advantage when writing larger applications though.