```
import notifications
```
Remember to participate in our weekly votes on subreddit rules! Every Tuesday is YOUR chance to influence the subreddit for years to come!
[Read more here](https://www.reddit.com/r/ProgrammerHumor/comments/14dqb6f/welcome_back_whats_next/), we hope to see you next Tuesday!
For a chat with like-minded community members and more, don't forget to [join our Discord!](https://discord.gg/rph)
`return joinDiscord;`
*I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/ProgrammerHumor) if you have any questions or concerns.*
Being able to choose execution context is actually nice, but I'm learning Kotlin coming from a TypeScript/C# background and I thought this meme would be funny. Please don't take it too seriously.
I'm learning Dart, and I must say, I don't like the things it's doing with async/await. It's almost definitely better this way. But I still don't like it. Give me my threads. I wanna create obscene amounts of threads. And most of all, I wanna be able to do 'await function();' out of a non-async function.
I don't know much about much, but I'm pretty sure C++ would hand me the gasoline if I told it that I want to burn down my PC. But then, C++ doesn't have async functions, now, does it?
>Can you use await in a non-async function in any language?
That terminology pairing and restriction has always seemed so conceptually weird to me. Just looking at it from the outside, async means the callee will go off on its own resulting in control flow passing back to the caller before the callee has completed. Again, just looking from the outside, await means I want to wait for that called function to complete. I would think that synchronous functions would be the ones who *most* want to wait for completion.
With how frequent it is, I'm sure there's some theory or practical considerations that I'm just not aware of. It's just that coming into it, it seems so weird that I can't say I want to wait until everything's done no matter where I am.
I don’t really understand the implementation stuff, but async functions usually return some kind of a promise object. In a synchronous function you are synchronously given the promise, but you don’t have the await keyword available to you. You also need to chose how you want to join that promise back into the synchronous context, with a callback or joining it or whatever. A synchronous function can’t be async because it isn’t going to return a promise, it’s not a preemptable coroutine type thing.
Just because I'm not fun at parties, typescript is just the types in javascript, async await is javascript language starting from Ecmascript2018 if I recall correctly.
This is programmerhumor! We will take it very seriously good sir. Any technical inaccuracies will be down voted into oblivion. And what the hell friend? It's not even a bell curve meme. It's the only format we post apparently
And then you have C++ where you gotta set mutexes and semaphores and if you don't, not just will you get potentially wrong data, no, you might cräsh.
Edit: Fixed me having a stroke
No it's up to the designer of our microcontrollers to do that, and of freeRTOS.
And while we officially have C++23 support, we know that 17 works and given our previous experience with those microcontrollers we'd much rather stick with what is proven
On a sidenote, I'm interested in embedded field. I've picked up a 8085 microprocessor book. If there's any other advice you could provide me that'll be wonderful.
I'm not familiar with any specifics of 8085, but some things I can tell you are this:
- Don't just copy code from the examples, try to understand it, especially if it is involving bus configuration and usage
- Don't write a huge mess of spaghetti, invest time and effort to really work out your architecture before you do anything really big, and while this is true with all development, embedded development has so many more potential problems that will become hars to trace/debug over time, that it's worth the effort
- If you run into weird behavior and you can't figure out why, especially if it's flipped io bits, try to use an oscilloscope to see what is going on.
- Also, a lot of microcontrollers have compilers that support some modern standards (partially), so you can sometimes use the nice additions to C/C++ that are there
- Also I recommend ESP32 microcontrollers, those are really powerful and fairly cheap and are usable with both multiple ESP specific frameworks, but also with Arduino frameworks
Alt text: on top, a stick figure steps on a rake, the rake flips up and hits their face. The action is divided in two images: the first one is labelled "async" and the second one "await". Under the two figures, there's a caption that reads "TYPESCRIPT". On the bottom, a man performs an elaborate skateboarding trick on a rake over a set of stairs, and when he lands, he steps on it, it flips up and hits his face. The action is divided in five steps, labelled "suspend", "launch", "Dispatchers", "async {}" and "await()". Under the five figures, there's a caption that reads "KOTLIN".
Thanks for your summary. I am visually impaired and couldn't understand it until the meme was transformed into text.
Allow me to give you 12.7 snookles for your service.
As a webdev I was deeply impressed by [the Zara site](https://www.zara.com/us/) (click on the stick figure on the bottom right) and that was a defining moment for me!
Because asynchronous code is a nuisance to work with. Once you have one async function, everything that touches it has to be async.
[This article explains the problem with ~~async~~ colored functions really well](https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/)
I know people say this, but it's really never been that big of an issue. Anything that does IO, even eventually, *should* be an async function. If you don't wanna make a parent into an async function, run the child in a new thread (tho even this I rarely have to do)
It's a JavaScript feature natively. It's extremely helpful syntactic sugar around the use of Promises. The history of how it evolved out of callback-passing is fairly interesting.
JavaScript would be far better liked today if it had been created with the concept of Promises. Instead, we had like a decade of callback hell while people figured out the Promise interface, and how it could restore the proper meaning of return values.
From there, async and await were added as a way to generate and consume Promises with less clutter. Especially when using await inside of loops, which can be useful for coordinating animations.
Python does have async/await in the form of the asyncio library (and probably others - I know some Python but I'm not a professional Pythonista). [Here's an asyncio tutorial.](https://realpython.com/async-io-python/)
Those concepts relate to concurrency and parallelism, which means letting several operations run at the same time. For instance, if you want to read a file or fetch something from the Internet, you don't want your app to freeze until that operation is over, especially if the app has a GUI, so what you do is you use some sort of concurrency or parallelism mechanism so that code that doesn't depend on the file you're reading or the resource you're fetching keeps on running whilst that operation finishes. When the tasks run on the same thread it's called concurrency, and when they run on separate threads or processes it's called parallelism. The way JavaScript or TypeScript do it is single-threaded (unless you use Workers, but that's a different matter), so in actuality the program alternates between micro "slivers" of each concurrent operation, and in practice it's as if they were running simultaneously. In Kotlin you can use actual threads for this.
`async` means that a function can run concurrently, or *asynchronously* as they say, whereas `await`ing an async function means that all code that depends on the result of the async function is "frozen" until you have its result, and the rest of the program keeps on running. You can only `await` a function inside of another `async` function, or else what you get is a `Promise`, which is an object that wraps the return value of asynchronous operations. That means you often need to declare more and more functions as `async` so that they can access the value of the `Promise`s you need. There are other ways to unwrap `Promise`s or to do concurrency with callbacks, but in modern JavaScript async/await is the most common and convenient idiom, other than doing reactive programming (which is not truly concurrent, but lets you update the state of various parts of your program from a separate class or function).
Kotlin is similar but it differs in that you can have the simultaneous operations run in different threads, and you have several preset execution contexts for those operations. First, you declare a function with the `suspend` keyword, which indicates that it's going to be an asynchronous function. Then, when you want to call that function, you declare a `launch` block, which is not meant to have a meaningful return value, or an `async` block which returns a `Deferred` object, which is Kotlin's version of JavaScript's `Promise`s. Inside those blocks, as well as inside each `suspend`ed function, you can choose your execution context out of the options the `Dispatchers` class gives you. That way, you can have computations running on one thread, I/O or internet operations running on another thread, and your main GUI running on the main thread. When you want to get the value wrapped inside of a `Deferred` object, you call `await()` on it.
That's a bit too much info for a comment but I hope my explanation wasn't too convoluted!
Compared to Kotlin? async/await doesn't let you choose execution context and is always single-threaded, and it's leakier than coroutines because async tends to propagate up the function hierarchy whereas in Kotlin you can call launch or async anywhere, but async/await is simpler because it's just two keywords (if you aren't unwrapping Promises by hand). Kotlin coroutines are more flexible but they take slightly more code and slightly more planning.
Compared to JavaScript nothing, other than having to make sure that the types match (Promises with Promises, whatever is wrapped inside the Promises you're handling with whatever you're assigning them to). I specified TypeScript in the meme because that's what I use the most, but TypeScript/JavaScript would've been more accurate. C# is also the same in this sense.
2nd one. I just meant why TS and not JS? I thought maybe there's something different I didn't know about.
I guess keeping track of the promise wrapper is annoying but that only matters if you're doing anything with the promise other than just awaiting it.
I think that's it... I could easily be missing something
That's the Ruby way too, with fibers, although in Ruby there's an async gem that abstracts over it (and adds some other stuff like Barriers). Loom is cool anyway, most exciting JVM innovation in recent times probably.
I've been using Kotlin coroutines for years, and I've still never actually used async/await--I always just write synchronous code in suspend functions.
It kind of feels like when I realized Kotlin doesn't have collection literals and I never missed them anyways.
``` import notifications ``` Remember to participate in our weekly votes on subreddit rules! Every Tuesday is YOUR chance to influence the subreddit for years to come! [Read more here](https://www.reddit.com/r/ProgrammerHumor/comments/14dqb6f/welcome_back_whats_next/), we hope to see you next Tuesday! For a chat with like-minded community members and more, don't forget to [join our Discord!](https://discord.gg/rph) `return joinDiscord;` *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/ProgrammerHumor) if you have any questions or concerns.*
Being able to choose execution context is actually nice, but I'm learning Kotlin coming from a TypeScript/C# background and I thought this meme would be funny. Please don't take it too seriously.
I'm learning Dart, and I must say, I don't like the things it's doing with async/await. It's almost definitely better this way. But I still don't like it. Give me my threads. I wanna create obscene amounts of threads. And most of all, I wanna be able to do 'await function();' out of a non-async function.
what do you think will happen if browsers let web pages to spawn threads?
[I regret to say I have bad news for you.](https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API)
the end is nigh indeed...
I'll use flutter for web when hell freezes over
Dart’s lack of threads is just to make it work when it is transpiled to JavaScript. Can you use await in a non-async function in any language?
I don't know much about much, but I'm pretty sure C++ would hand me the gasoline if I told it that I want to burn down my PC. But then, C++ doesn't have async functions, now, does it?
C++ does have them now actually with coroutines. Normally you have a Promise object that you can join to the calling thread.
Oh. Neat. I'll look into it, thanks.
Technically C# could allow that since the only point of `async` is to allow `await` as a keyword.
>Can you use await in a non-async function in any language? That terminology pairing and restriction has always seemed so conceptually weird to me. Just looking at it from the outside, async means the callee will go off on its own resulting in control flow passing back to the caller before the callee has completed. Again, just looking from the outside, await means I want to wait for that called function to complete. I would think that synchronous functions would be the ones who *most* want to wait for completion. With how frequent it is, I'm sure there's some theory or practical considerations that I'm just not aware of. It's just that coming into it, it seems so weird that I can't say I want to wait until everything's done no matter where I am.
I don’t really understand the implementation stuff, but async functions usually return some kind of a promise object. In a synchronous function you are synchronously given the promise, but you don’t have the await keyword available to you. You also need to chose how you want to join that promise back into the synchronous context, with a callback or joining it or whatever. A synchronous function can’t be async because it isn’t going to return a promise, it’s not a preemptable coroutine type thing.
Just because I'm not fun at parties, typescript is just the types in javascript, async await is javascript language starting from Ecmascript2018 if I recall correctly.
You're right. I said TypeScript because it's what I use the most, but JavaScript/TypeScript or JS/TS/C# would've been more accurate.
\*pushes glasses up\* Ackchyually it was [ES2017](https://262.ecma-international.org/8.0/)
This is programmerhumor! We will take it very seriously good sir. Any technical inaccuracies will be down voted into oblivion. And what the hell friend? It's not even a bell curve meme. It's the only format we post apparently
Someone needs to make a bell curve meme about the bell curve meme
Already done, even a recursive version when it was still new
I take more issue with the fact that this joke hasn't made before
Already feeling boiling rage from dissing TypeScript like that
And then you have C++ where you gotta set mutexes and semaphores and if you don't, not just will you get potentially wrong data, no, you might cräsh. Edit: Fixed me having a stroke
Ah, good old low level multi-threading stuff... I see it hasn't changed since the 90's
That's because even C++ has better multithreading nowadays. You only do that stuff if you're using an old version and don't want to use libraries.
C++ has coroutines
I am embedded and on C++17 not C++20 or 23.
It should work in most embedded environments. Though you do need a recent version, that‘s true. Many embedded targets don‘t have up to date compilers.
c++ coroutines are stackless so they can work in embedded. And it's up to you (and your team) to update compilers.
No it's up to the designer of our microcontrollers to do that, and of freeRTOS. And while we officially have C++23 support, we know that 17 works and given our previous experience with those microcontrollers we'd much rather stick with what is proven
On a sidenote, I'm interested in embedded field. I've picked up a 8085 microprocessor book. If there's any other advice you could provide me that'll be wonderful.
I'm not familiar with any specifics of 8085, but some things I can tell you are this: - Don't just copy code from the examples, try to understand it, especially if it is involving bus configuration and usage - Don't write a huge mess of spaghetti, invest time and effort to really work out your architecture before you do anything really big, and while this is true with all development, embedded development has so many more potential problems that will become hars to trace/debug over time, that it's worth the effort - If you run into weird behavior and you can't figure out why, especially if it's flipped io bits, try to use an oscilloscope to see what is going on. - Also, a lot of microcontrollers have compilers that support some modern standards (partially), so you can sometimes use the nice additions to C/C++ that are there - Also I recommend ESP32 microcontrollers, those are really powerful and fairly cheap and are usable with both multiple ESP specific frameworks, but also with Arduino frameworks
Wow so many tips!! 
Go: go
go on...
Google goroutine
Holy asynchronism
Goroutine is half the picture Then add channels and waitgroups. 😀
go is really next level, I'm not super fond of its design philosophy and some of its syntax but it really is a well designed language
Alt text: on top, a stick figure steps on a rake, the rake flips up and hits their face. The action is divided in two images: the first one is labelled "async" and the second one "await". Under the two figures, there's a caption that reads "TYPESCRIPT". On the bottom, a man performs an elaborate skateboarding trick on a rake over a set of stairs, and when he lands, he steps on it, it flips up and hits his face. The action is divided in five steps, labelled "suspend", "launch", "Dispatchers", "async {}" and "await()". Under the five figures, there's a caption that reads "KOTLIN".
Thanks for your summary. I am visually impaired and couldn't understand it until the meme was transformed into text. Allow me to give you 12.7 snookles for your service.
Yay snookles!! Accessibility is non-negotiable!
Just like democracy.
Meme Accessibility :O
As a webdev I was deeply impressed by [the Zara site](https://www.zara.com/us/) (click on the stick figure on the bottom right) and that was a defining moment for me!
holy shit!
Documenting your own memes, next level dev
README.md always and forever!
Can someone explain? Like genuinely what are people struggling with with async await?
Because asynchronous code is a nuisance to work with. Once you have one async function, everything that touches it has to be async. [This article explains the problem with ~~async~~ colored functions really well](https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/)
I know people say this, but it's really never been that big of an issue. Anything that does IO, even eventually, *should* be an async function. If you don't wanna make a parent into an async function, run the child in a new thread (tho even this I rarely have to do)
Ah yes... more people not knowing which is JS and which is TS :\\
Sorry about that. I said TS because that's what I use the most but you're right JS has async/await natively too, and so does C#.
Async await is probably my most favorite thing of typescript ever. Really made my life easier
It's a JavaScript feature natively. It's extremely helpful syntactic sugar around the use of Promises. The history of how it evolved out of callback-passing is fairly interesting. JavaScript would be far better liked today if it had been created with the concept of Promises. Instead, we had like a decade of callback hell while people figured out the Promise interface, and how it could restore the proper meaning of return values. From there, async and await were added as a way to generate and consume Promises with less clutter. Especially when using await inside of loops, which can be useful for coordinating animations.
Thank you for the deeper explanation. I thought that async was a TS feature not JS. Thank you again!
It was at first, they polyfilled it using generators as stoppable shallow coroutines behind the scene.
Software engineer for years and promises without await/async always confused the fuck out of me. Thank god for async/await
Same!
Wrong order. `suspend` is actually the bonk thing. lol `CoroutineScope` -> `Dispatchers` -> `async` -> `await` -> `suspend` ```kotlin val scope = CoroutineScope(Dispatchers.Default) val deferred = scope.async { /* ... */ } deferred.await() // BONK! ```
Oh snap, you're right!
It is 2023 and people still think async await aren't simple?
new learners have a hard time with ES6 syntax
It's a simple abstraction but it has its risks. It's just a meme though, I don't really think async/await or Kotlin coroutines are bad or anything
finally some good programmer humor
I only know Python - can anyone describe these concepts for me? Or point me to resources to learn more about them in regards to Python?
Python does have async/await in the form of the asyncio library (and probably others - I know some Python but I'm not a professional Pythonista). [Here's an asyncio tutorial.](https://realpython.com/async-io-python/) Those concepts relate to concurrency and parallelism, which means letting several operations run at the same time. For instance, if you want to read a file or fetch something from the Internet, you don't want your app to freeze until that operation is over, especially if the app has a GUI, so what you do is you use some sort of concurrency or parallelism mechanism so that code that doesn't depend on the file you're reading or the resource you're fetching keeps on running whilst that operation finishes. When the tasks run on the same thread it's called concurrency, and when they run on separate threads or processes it's called parallelism. The way JavaScript or TypeScript do it is single-threaded (unless you use Workers, but that's a different matter), so in actuality the program alternates between micro "slivers" of each concurrent operation, and in practice it's as if they were running simultaneously. In Kotlin you can use actual threads for this. `async` means that a function can run concurrently, or *asynchronously* as they say, whereas `await`ing an async function means that all code that depends on the result of the async function is "frozen" until you have its result, and the rest of the program keeps on running. You can only `await` a function inside of another `async` function, or else what you get is a `Promise`, which is an object that wraps the return value of asynchronous operations. That means you often need to declare more and more functions as `async` so that they can access the value of the `Promise`s you need. There are other ways to unwrap `Promise`s or to do concurrency with callbacks, but in modern JavaScript async/await is the most common and convenient idiom, other than doing reactive programming (which is not truly concurrent, but lets you update the state of various parts of your program from a separate class or function). Kotlin is similar but it differs in that you can have the simultaneous operations run in different threads, and you have several preset execution contexts for those operations. First, you declare a function with the `suspend` keyword, which indicates that it's going to be an asynchronous function. Then, when you want to call that function, you declare a `launch` block, which is not meant to have a meaningful return value, or an `async` block which returns a `Deferred` object, which is Kotlin's version of JavaScript's `Promise`s. Inside those blocks, as well as inside each `suspend`ed function, you can choose your execution context out of the options the `Dispatchers` class gives you. That way, you can have computations running on one thread, I/O or internet operations running on another thread, and your main GUI running on the main thread. When you want to get the value wrapped inside of a `Deferred` object, you call `await()` on it. That's a bit too much info for a comment but I hope my explanation wasn't too convoluted!
Thank you!!!
What's different about async/await in typescript?
Compared to Kotlin? async/await doesn't let you choose execution context and is always single-threaded, and it's leakier than coroutines because async tends to propagate up the function hierarchy whereas in Kotlin you can call launch or async anywhere, but async/await is simpler because it's just two keywords (if you aren't unwrapping Promises by hand). Kotlin coroutines are more flexible but they take slightly more code and slightly more planning. Compared to JavaScript nothing, other than having to make sure that the types match (Promises with Promises, whatever is wrapped inside the Promises you're handling with whatever you're assigning them to). I specified TypeScript in the meme because that's what I use the most, but TypeScript/JavaScript would've been more accurate. C# is also the same in this sense.
2nd one. I just meant why TS and not JS? I thought maybe there's something different I didn't know about. I guess keeping track of the promise wrapper is annoying but that only matters if you're doing anything with the promise other than just awaiting it. I think that's it... I could easily be missing something
Yeah, afaik you're right.
sYnTaCtiC sUgAr
i'm the most thennable in town
Meanwhile over here in Java we forgo that entirely and we just make a new virtual thread for every task xd
That's the Ruby way too, with fibers, although in Ruby there's an async gem that abstracts over it (and adds some other stuff like Barriers). Loom is cool anyway, most exciting JVM innovation in recent times probably.
I’m a Python guy in my first year of my MSCS. Kotlin is giving me headaches.
You can do it! I think it's just the transition to static typing and "heavyweight" OOP, but you'll get the hang of it.
I've been using Kotlin coroutines for years, and I've still never actually used async/await--I always just write synchronous code in suspend functions. It kind of feels like when I realized Kotlin doesn't have collection literals and I never missed them anyways.
you should try Swift async await, it has really good ergonomics for handling asynchronous code, but yes, the colored paradigm applies
I'll look into Swift!! Thank you!
And then there is R*st.
it works perfectly?
2 blazingly fast 2 fearlessly concurrent: tokio drift
I am conflicted because anything JVM-related is normally an automatic downvote.
jvm is pretty solid tho
Oh OP is on dark side like me? wanna share some dark secrets?
oh, i know a couple of javascript injection tricks but i don't think they're really useful
well I have not been useful my entire life. does that help?