[samsquire]

Why don't you like async/await?

8 years ago I wrote a npm package that turned code that looks like this:

    tcp.send("syn", function(syn) {
        console.log("received", syn);
        tcp.send("syn-ack", function(synack) {
          console.log("received", synack);
          tcp.send("ack", function(ack) {
            console.log("received", ack);
         });
     });
   });

into this:

  seq([tcp, console], function(tcp, console) {
    var syn = {}; var synack = {}; var ack = {};
    tcp.send("syn", this(syn));
    console.log("received %s", syn);
    tcp.send("syn-ack", this(synack));
    console.log("received %s", synack); 
    tcp.send("ack", this(ack));
    console.log("received %s", ack); 
  });

it was never ready for production use, but it showed that synchronous code illusion can be created from callbacks.

How would you prefer to write asynchronous code?

How does Loom handle resource starvation problem? If a thread puts a while (true) {} in there somewhere, can that thread be preempted away from that kernel thread?

[vore]

I think async/await is just noise: if you already have a heavy runtime like JavaScript or Python does (I forgive Rust for this one because it's so tied to reducing runtime overhead), you might as well handwave the distinction between green threads and system threads away and just pretend all asynchronous calls are synchronous (e.g. like how the eventlet or the Go runtime do it): it's painful when you have to call an asynchronous function from a synchronous context!

If you put while (true) { } in an asynchronous function, wouldn't you also have a resource starvation problem? For what it's worth though, Loom threads are planned to be fully preemptible.

[thom]

Sounds like we’re agreeing - nobody _wants_ to write async code cos it’s terrible. You didn’t quite perfect the syntax above but I’m not denying it’s possible - Clojure treats async as a library, not a fundamental language feature, for example. And now with Loom the implementation is even simpler. People want to write synchronous code that can run in parallel without having to do something weird. History will hopefully prove that this is best solved as an implementation detail, not as part of a language’s semantics.