Ygtjki

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.

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.

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.

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.

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.

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.