> A thread is the exact concept needed to describe that and preserve “if else then” sequential code.

I suggest looking at C# and Javascript that implement async very, very well.

The difference is that with conventional threading semantics, when you join a thread, it doesn't return a result. You still need to write some kind of "thing" to get your result from the subthread to whatever's waiting on it. (C# also provides a less-well-known BeginInvoke mechanism which is somewhat cleaner than join.)

In contrast, the promise (Javascript) or task (C#) has a result. Instead of joining a thread, the await keyword gets the result, just like calling a method.

> Linux handles thousands of threads just fine.

Yes... And no...

It doesn't matter what OS you're on, each thread needs its own allocated stack space and has the overhead of context switching. "async" optimizes that by putting data that would normally go into many different stack spaces into the heap and jumping around among concurrent operations without the context switch.

Again, depending on what you're doing, that's either splitting hairs, or really making a tangible improvement. But you can't argue that more allocated stacks, and more context switches, is faster than doing it in process. At that point you're arguing with fact.

> C#/JavaScript

I am familiar with how these are implemented. My opinion is the same. Yes you can implement slightly lighter weight threads in a language itself.

> It doesn't matter what OS you're on, each thread needs its own allocated stack space and has the overhead of context switching

This is a quantitative question. I know what it does, the question is how much slower it is than whatever async construct you want to use.

Too late to edit: I should also point out that Rust has the same issue with joining a thread: It doesn't give you the result of the function; unlike awaiting on a promise.

(I really struggled with async rust, so I'll admit that I don't remember the name of the type that represents the promise.)