I honestly don't know, why async got so popular. It seems like the entire reason for doing it was that some blokes were hellbent on using JS on a server and couldn't fathom that a second thread might be a good idea.
I think they’re talking about the async/await syntax that’s common now in high level languages. Like, what’s the difference between that, or using actual threads? The only advantage I see is that it’s significantly easier/faster to use hence why it’s popular with languages like JS.
De facto it is callback hell, though. Debugging Async code horrible and let's be honest here: Async is just global-synchronized (or whatever it's called it not-Java) with extra steps.
After using both extensively I would argue async code is easier to read. It has a lot less nesting. And generally easier to read code is a good thing so I'm all for async.
That's a very common misconception. async is just a scheduling tool that runs at the end of event loop (microtask queue). It still runs on the main thread and you can still lock up your UI. You'd need Web Workers for actual multi-threading.
If you need to get multiple pieces of data for one request Async is great, but why would you work on different requests in the same thread? Why slow down one request because the other needs a bunch of computation?
Async is good because threads are expensive, might aswell do something else when you need to wait for something anyways.
But only having async and no other thread when you need some computation is obviously awful.. (or when starting anothe rthread is not easily manageable)
Thats why i like go, you just tell it you want to run something in parallel and he will manage the rest.. computational work, shift current work to new thread.. just waiting for IO, async.
Nah, they're very similar, really. You generally kick IO heavy stuff you don't need immediately off to async await.
There are a few more applications of it in C# since you don't have the "single thread" to work with like in JS. And the actual implementation under the hood is different, sure. But conceptually they're similar. Pretty sure JS was heavily influenced by C#'s implementation and syntax.
Imagine a webser or proxy and for every incoming request it creates an new thread 💣
Yes you're right if it's a second or third thread it is/may be fine. But if you're i/o bound and your application has to manage quite a lot of that stuff in parallel, there is no way around delegating that workload to the kernel's event loop. Async/Await is just a very convenient abstraction of that Ressource.
async/await is just callback() and queueMicrotask wrapped up into a neat package. It's not supposed to replace multi-threading and confusing it for such is dangerous since you can still stall your main/UI thread with Promises (which async also wraps).
(async and await are also technically different things, but for the sake of simplicity here, consider them a pair.)
Async got popular when the choices for clientside code in the browser were "Javascript" or "go fuck yourself." It's an utterly miserable way to avoid idiotic naive while() stalling. But it was the only way.
async/await could be useful if one creates an entire program designed on and for it, but it stops being acceptable as soon as I need two .thens inside of each other because I tried to use fetch in a non-async app without race conditions