Why do we need to put await in front of async calls? I hate it. In other languages like python you don't have to. Why can be await not be the default so I don't have to write it and specify asynchron when I need it?
> In other languages like python you don't have to.
I'm confused since "I don't have to do this in python" is probably the worst choice you could make to try and run away from this. Python does have async/await and the semantics are very similar (in fact they're more restrictive in some ways). You will get the same interpreter errors if you try to call async functions and awaits in a non-async function.
You're more likely upset that Promises in javascript are more common, but if you understood what the js interpreter is doing in an async event loop and the backing structures needed to make those calls you'd understand the need for the correct annotations.
If your gripe is with just needing await/async in general, you should know you don't actually ever need to use await/async. The .then chaining form is an alternate and equivalent way of handling promises.
Since, if you've read this far, you're probably saying to yourself "this is guy is dumb and doesn't really understand what I'm talking about". I'll give you a rope I'll claim you don't want and which solves the problem you think you have.
You'll be happy to learn you are not correct to say you need to use async await or .then. You can break out of the async nesting and just wrap whatever async call you can't get away from in a synchronous wrapper.
The answers (with much stronger warnings than I've given you) await you here
(assuming this is JavaScript): there's a difference between awaiting a promise, and just declaring a promise.
Sometimes you want to declare a few promises first, before running await Promise.all() - sometimes, you don't even care for the results of all of the promises, and just want the first result to complete (promise.race)
This is clear but in most cases I just don't care if it is a promise. If I need more control it is possible, but for the 99% cases I find it annoying writing await. This is also slowing down, because you need to know or look it up if the call returns a promise.
In that case the promises are a waste of time because you always want to wait for them to complete. Very often you don't need to and your code will be quicker.
It's at least cleaner than a bunch of chained .then()s or nested callbacks, which is what we had to do in the old days.
If you don't want to use async/await, you can still do it the old-fashioned ways. But it's not really that difficult to just wrap whatever you're doing in an async call, is it? e.g.
Will cause all of those to run in sequence as synchronous operations one after another. Promise.all() can help with concurrent async things, or you can use a queuing library like p-throttle/p-limit if there are rate limits to observe.
Yeah, it's a bit of syntactic complexity, but once you get the hang of it, they're not so bad and let you more cleanly think about which operations are synchronous & blocking and which can be async in the background (important for both performance and UX).
I'm confused since "I don't have to do this in python" is probably the worst choice you could make to try and run away from this. Python does have async/await and the semantics are very similar (in fact they're more restrictive in some ways). You will get the same interpreter errors if you try to call async functions and awaits in a non-async function.
https://docs.python.org/3/library/asyncio.html
You're more likely upset that Promises in javascript are more common, but if you understood what the js interpreter is doing in an async event loop and the backing structures needed to make those calls you'd understand the need for the correct annotations.
If your gripe is with just needing await/async in general, you should know you don't actually ever need to use await/async. The .then chaining form is an alternate and equivalent way of handling promises.
Since, if you've read this far, you're probably saying to yourself "this is guy is dumb and doesn't really understand what I'm talking about". I'll give you a rope I'll claim you don't want and which solves the problem you think you have.
You'll be happy to learn you are not correct to say you need to use async await or .then. You can break out of the async nesting and just wrap whatever async call you can't get away from in a synchronous wrapper.
The answers (with much stronger warnings than I've given you) await you here
https://stackoverflow.com/questions/9121902/call-an-asynchro...