This is my favorite version of this so far.
this post was submitted on 28 Jan 2024
25 points (96.3% liked)
Programmer Humor
32175 readers
289 users here now
Post funny things about programming here! (Or just rant about your favourite programming language.)
Rules:
- Posts must be relevant to programming, programmers, or computer science.
- No NSFW content.
- Jokes must be in good taste. No hate speech, bigotry, etc.
founded 5 years ago
MODERATORS
I'm gett the ing UDP same vib joke
It's funny but the random capitalization is distracting
it's not that random, it's the original text
Ok so you had to know the original post, ok
I wouldn't say you HAVE to know the original but it's pretty common in memes for text to be replaced and the person doing the replacing to not know the original font.
You at least have to know that it's a meme format. Otherwise it just looks like someone complaining about async with a bad crop.
I'm actually laughing out loud at the amount of whitespace because ~~thread~~ routine is still executing lmao
We're here asyncronously waiting for the rest of the meme.
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:
I see, thanks
?
I PROMISE the rest will come eventually
that is going to take some RESOLVE
You're just being lazy.
Async are lazy loaded by design in rust, so... Yeah
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.
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 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.
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.
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?
You aren't slowing down anything. If you didn't use async that thread would be blocked.
You'd need a thread per request even though they are sat doing nothing while waiting for responses.
Instead when you hit an await that thread is freed for other work and when the wait is over the rest of the code is scheduled to run.
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.
It can lock up a UI doing cpu bound work. Making a web request, no. Preventing the ui thread from waiting on native IO is what async was created for.
Preventing the ui thread from waiting on native IO is what async was created for.
Citation needed. async just a wrapper for Promises. IO isn't related, just commonly used with it.
NodeJS's IO and fetch are just promises. (And NodeJS used to use callback(err, response) before adding promises.).
Yes I’m simplifying a LOT, but in the context of background web calls, that was what callbacks became so important for. XMLHttpRequest in IE 5 sparked the Ajax movement and adventures in nested callbacks.
Prior to that, the browser had window.setTimeout and its callback for delays and animation and such - but that’s it.
The main purpose of all this async callback stuff was originally, and arguably still is (in the browser), for allowing the ui event loop to run while network requests are made.
NodeJS didn’t come into the picture for almost 10 years or so.
Yeah, that's a big simplification and I get it. But the async syntax itself syntax "sugar" for Promises. It's not like C# or Java/Android where it will spawn a thread. If you take a JSON of 1000 rows and attach a promise/await to each of them, you won't hit the next event loop until they all run to completion.
It's a common misconception that asynchronous means "run in background". It doesn't. It means run at end of current call stack.
Prior to that, the browser had window.setTimeout and its callback for delays and animation and such - but that’s it.
And you STILL have to call setTimeout in your async executions or else you will stall your UI.
Again async is NOT background. It's run later. async wraps Promise which wraps queueMicrotask.
I’m well aware how async works in the single threaded js environment. All code blocks the main thread! Calling await on an async operation yields back.
You’re right, async is commonly mixed up with multi-threaded. And in fact in many languages the two things work hand in hand. I’m very aware of how it works in JavaScript.
We are agreeing. Don’t need more info.
Async rust with the Tokio Framework is pretty cool. Need none of that JS bloat for async.
Async Rust sucks. I hate how many libraries use it, forcing it apon you.
You suck, I hate how your comment was forced "apon" me. Anyone who claims things that they can easily avoid if theyre so opinionated against them are "forced upon" them are always pathetic people.
Have you programmed with rust a day in your life? Once you introduce one library that requires Tokio async you have to start wrapping all your calls that involve it in async shit.
So many better concurrency patterns out there.
And these libraries are not easily avoidable. Ex: most AWS libraries require it.
And forgive me for a stupid typo, I have had little sleep the last week but you are an asshole that thinks belittling people somehow makes you right so it doesn't really matter.
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?
Threads don't need to be expensive.
Well too bad cause they are.
Go ahead and spin up a web worker and transfer a bunch of data to it and tell us how long you had to wait.
The only way I have heard threads are expensive, in the context of handling many io requests, is stack usage. You can tell the os to give less memory (statically determined stack size) to the thread when it's spawned, so this is not a fundamental issue to threads.
Go ahead and spin up a web worker and transfer a bunch of data to it and tell us how long you had to wait.
Time to transfer data to one thread is related to io speed. Why would this have anything to do with concurrency model?
Well I just told you another one, one actually relevant to the conversation at hand, since it's the only one you can use with JavaScript in the context of a web browser.
You cant say async is the fundamentally better model because threading is purposely crippled in the browser.
The conversation at hand is not "how do io in browser". Its "async is not inherently better than threads"
No, because async is fundamentally a paradigm for how to express asynchronous programming, i.e. situations where you need to wait for something else to happen, threading is not an alternative to that, callbacks are.
Threads are callbacks.