STOP DOING ASYNC

This is my favorite version of this so far.
- I'm gett the ing UDP same vib joke
- It's funny but the random capitalization is distracting

?
- I PROMISE the rest will come eventually
  
  that is going to take some RESOLVE
  
  You're just being lazy.
- You must .await before you can have the Result. Then you can use ?

For those who don't get it, it's the "stop doing science" meme.

I'm actually laughing out loud at the amount of whitespace because ~~thread~~ routine is still executing lmao

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.
- If you are waiting for IO, why would you block your current thread and not let it do something else? Async does not only exist in 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.
- A huge amount of time in apps is spent waiting for IO, database or web requests to complete.
  Async prevents locking a thread during this wait.
  If you're handling a large amount of requests in a web server, for example, it allows other requests to progress while waiting for these operations.
  Threads are also expensive to start and manage.
  Also handling threads manually is a pain in the ass.
  
  Async prevents locking a thread during this wait.
  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?
- Because the alternative is a series of ridiculously nested call backs that make code hard to read and manage?
  I honestly can't fathom how anyone would dislike async programming.
- 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.
  
  The "do something while waiting for something else" is not a reason to use async. That's why blocking system calls and threads exist.
  Threads don't need to be expensive. Max stack usage can be determined statically before choosing the size when spawning a thread.
  Any other reasons?
- Ok, I'm a c# developer and I use async await quite extensively. Is it different in JS? Or am I missing something?
  
  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.
- Async rust with the Tokio Framework is pretty cool. Need none of that JS bloat for async.
  
  Honestly I can't wrap my head how to effectively put computation into a thread, even with Tokio.
  All I want is something like rayon where you got a task queue and you just yeet tasks into a free thread, and await when you actually need it
  Might be too much JS/TS influence on me, or that I can't find a tutorial that would explain in a way that clicks for me
  
  Async Rust sucks. I hate how many libraries use it, forcing it apon you.
- 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
- Observables are your friends

Honestly, I don't get it.
Is it about the syntax sugar? Would you like to use callbacks instead?
Async programming is when you achive concurrency even with one thread. It's needed. There's no alternative to this.
- It's a meme, it's not actually saying not to use async:
  https://knowyourmeme.com/memes/stop-doing-math
  
  I see, thanks

We're here asyncronously waiting for the rest of the meme.

less async more nsync