What does this even mean, how can you do any form of modern computation without async?

async / await as they exist in JavaScript, Python, and Rust aren’t the only way to execute tasks concurrently.

That’s what I’m asking - did the comment mean that the async/await pattern is bad, or that asynchronous programming in general is bad?

asynchronous programming is the bee's knees, and my preferred mode

Asyc/await pretends to be synchronous and gets all tied in horrible knots when the sunk costs mount

Writing IO without blocking has always been second nature to me

But they are a darn convenient mental model if you’re just trying to do some basic async. The alternatives are harder to wrap your head around. Unless I’m missing some other cool pattern.

> Unless I’m missing some other cool pattern.

Explicit state machines

Completely disagree.

Async as a paradigm has probably created billions of dollars in that it's allowed many many many developers to reasonably scale beyond what they could've otherwise.

And I disagree with your disagreement :)

Just some background first: one of the billion dollar mistakes is the null pointer which is a special value to be assigned to any type. It was inherent in the first high (today considered low) level languages. Those languages (C most importantly, then Java and nowadays even Go) enabled many more programmers to create programs and they likely would not have been able to, had they been forced to write assembly. So, it's a billion dollar mistake within a trillion dollar revenue.

The async now solves a similar practical problem but in the space of prallelism (or concurrency, in some cases). A different approach might have given us the same result, but a different implementation that might be just as approachable.

Optionals and Results have given us a better way than to have nulls, and maybe golang style channels could have given us a better way to handle async?

Agree wholesale. I've got a complex data reader built on a single server that receives tens of thousands of requests a day, and most tend to happen in a few hour window. Async was super important to scale to user requests by allowing non-blocking calls to not get captured behind blocking ones.

I think GP is arguing that green threads e.g. in Go is a better way to structure the same thing.

No. I had a nasty experience with Typescript's async/await and I am annoyed

I find async/await very confusing. It as one thing pretending to be another

I prefer my paradigms simple and straight

Async await is deceptively simple but very wiggly. Not straight at all. Loads of magic fairy dust obscuring what's really happening

It is helpful until it isn't and then it's very unhelpful

Wait they promised to not adopt the cancerous function coloring approach in wasm. Please tell me they didn't follow the dark path of JS

The plan is to support async without function colouring.

I recommend this talk by Luke Wagner on async plans in WASI 0.3 (https://youtu.be/y3x4-nQeXxc) for background on how it will work.

To summarise, from an API perspective, the caller and callee won't know if the other is async or not. When calling async from non-async, an event loop is inserted at link-time and it blocks.* When calling non-async from async, the callee will get suspended if it tries to do blocking IO. That still leaves the problem of long-running compute without IO in a non-async context, but at least you're not wasting CPU time in that scenario.

* If the host runtime already has an event loop, I assume the callee will get added to that.