For example turndeg(90), Move(10), PickupItem(), turndeg(180), Move(10) you treat errors as exceptions, if the robot fail to pickup the item, or if it ends up at the wrong place it's an exception.

Now if you put all these in try/catch, have the functions return error code (or 0 for success), or use callbacks, the code will be more "ugly" yes, but you then treat errors as "first class citizens", if the robot for example fail to pickup the item you want to try something else, maybe apply more vacum to the suction arm, or switch to a grip arm. And if the robot goes off course you want to make a course direction.

async/await, coroutines, futures, promises, do make the code "look nice", but that nice look comes from treating errors as exceptions.

Just to be clear, the audience for that tour is primarily Cloudflare engineers working on workerd / Workers runtime. Within that context, that's very much correct. The entire codebase is written using asynchronous I/O - synchronous I/O doesn't show up (or if it does, it's in weird parts I've never looked). Fibers are used sparingly in very specific contexts and we have very special code to make it memory efficient at our scale.

What question are you answering 'yes' to?

The callback is not a natural construct

According to who? It is very natural to anyone making a GUI or anything interactive for the firs time. Eventually I would try to move people to queueing up events and handling them all at the same time so that the order is easier to debug.

Coroutines are the latest silver bullet syndrome. Fundamentally you still need to synchronize and order data and that's the hard part. I don't know why students would need to do more than the classic interactive loop of:

1. get data

2. update state

3. interactive output (drawing a frame, moving a robot etc.)

Go's pretty much that idea. Make the threads light as coroutines (I think it's like 4k or 8k per goroutine) and give some basic messaging (channels) to go with it. Works well but some of the simplicity ended up biting it in the arse so there can be quite a bit of boilerplate in some cases.

Because looking at all the examples listed in the article, none of them seem like very idioms.

Years ago I attempted to build an experimental language with first-class resumable functions. Every function can be invoked by the caller through a special reference type called "quaint". The caller can resume or stop the execution of the function either after reaching a timeout, or after passing a "wait label":

https://github.com/bbu/quaint-lang

A typical CPU-intensive example where preemption is done by the caller after a certain timeout:

    entry
    {
        fibq: quaint(u32) = ~fibonacci(32 as u32);

        ps("At start: "), pu8(fibq@start), pnl();
        iter: u32 = 0:u32;

        do {
            wait fibq for 1000 msec;
            ps("Iteration "), pu32(iter++), pnl();
        } while !fibq@end;

        ps("At end: "), pu8(fibq@end), pnl();
        const value: u32 = *fibq;
        ps("Reaped value: "), pu32(value), pnl();
    }

    fibonacci(number: u32): u32
    {
        if number == 0:u32 || number == 1:u32 {
            return number;
        } else {
            return fibonacci(number - 1:u32) + fibonacci(number - 2:u32);
        }
    }

    entry
    {
        q: quaint(u64) = ~pointless_function();

        wait q until pointless_function::label_a;
        ps("At label_a: "), pu8(q@pointless_function::label_a), pnl();

        wait q until pointless_function::label_b;
        ps("At label_b: "), pu8(q@pointless_function::label_b), pnl();

        wait q until pointless_function::label_c;
        ps("At label_c: "), pu8(q@pointless_function::label_c), pnl();

        wait q;
        ps("At end: "), pu8(q@end), pnl();

        ps("Result: "), pu64(*q), pnl();
    }

    pointless_function: u64
    {
        i: u64 = 0 as u64;

        while ++i < 1000000:u64 {
            x: vptr = malloc(1024:usize);
            free(x);

            if i == 300000:u64 {
                [label_a]
            } elif i == 600000:u64 {
                [label_b]
            } elif i == 900000:u64 {
                [label_c]
            }
        }

        return i;
    }

But I have long been of the opinion that both languages are kind of an ill fit for the application. Python is making some headway and I think it might be a better fit; It has some advantages on legibility, it has an optional static typing system, and it does support coroutines.

A bit of an aside maybe, but the guy that made Quasar is behind project loom to add light weight threads to JVM which will become available in JVM 21 https://openjdk.org/jeps/444

I currently work on a project that involves Java code with a promise library, and Unreal Engine C++ code which does not and uses callbacks (and do async JS stuff in my personal projects), and both have to do asynchronous logic. The Unreal code is just so much harder to deal with.

Specific problems the Unreal code has:

- There's no "high level" part of the code that you can look at to see what the logic flow is.

- Many functions are side-effecty, triggering the next part of the sequential logic without it being clear that that's what they're doing. Like the handleFetchAccount() callback kicks off another httpRequest for the next step, but you wouldn't know that it does that just from the name.

I'd admit some of these problems might be mitigatable in a better written codebase though.

Consider this example algorithm, of several async steps,

1. Download a file into memory

2. Email a link to a review web page.

3. Wait for the user to review.

4. Upload the file to a partner.

5. Update a database.

You could implement this as callbacks. Callback from each step leads to the next being triggered. Downside - your business logic is spread across all the callbacks. You could mitigate this somewhat by defining a class with one method for each step, with those methods being defined in the same visual order as the algorithm. Then have each callbacks call a method. (The article shows something different but similar with its Command autoCommand pattern.)

Tricks like this only go so far. Imagine if the reviewer user had a choice of pressing 'approve' or 'reject' on the webserver interface, with the algorithm changing depending on their answer. How do you now represent the business logic so the programmer can follow it?

Such changes are easy in coroutines. Here is the algorithm with that variation in coroutine code,

    async def review(review_id, url):
      file_content = await download_large_file(url, review_id)
      ws_review_id = await create_webserver_review_page(file_content)
      await email_the_user(ws_review_id)
      result = await get_webserver_user_response(ws_review_id)
      if result: 
        await upload_to_partner(file_content)
      else:
        await alert_failure(review_id, file_content)
      await update_database(review_id, ws_review_id, result)

Neither stackful nor stackless coroutines work like this practice. The former suspends coroutines by saving and restoring the CPU state (and stack) and the latter compiles down to state machines, as mentioned in the article. Coroutines are functionally not equivalent to callbacks at all.

I found the article a great example of the kind of crap that passes for programming these days.