Manager: You can’t define an async function without using await.

Dev: Yes you can.

Manager: Well you shouldn’t, there’s no point!

Dev: Yes there is. It can turn blocking synchronous logic into work performed concurrently. In this case the perform—

Manager: It’s called async *await*. Async *AWAIT*! Did you hear the two parts to that? You shouldn’t ever have one without the other. THEY GO TOGETHER. Worrying about concurrency is for people who use callbacks which just goes to show how out of date your skills are. I’m reading a book on javascript and there are so many advanced techniques out there that I haven’t even seen you use ONCE!

Dev: …

*I looked at the book he’s reading, it’s from the < ES6 era… no wonder he doesn’t see me using any of those archaic patterns/hacks/workarounds…*

I feel you bro, I hate these kind of people too 🤦🏻‍♂️

When you said async await I thought you were talking about c#...

Even is he had the latest patterns it would be shit to complain about this. Just because something is new doesn't always make it better.

I have never seen my boss complain about using old patterns or new patterns. He just tries to get shit done. He is results oriented.

Your manager sounds like a complete fucking idiot.

What happens if you don't await an async method? It's the same as calling a method that returns a promise right? So is it a fire and forget thing?

@Crost I think it just makes code easier to follow and read because it prevents callback hell or nesting functions in functions in functions...

Oh god... Thinking about the code makes my head hurt...

But but my problem anymore :)

@Crost async functions/methods implicitly return promises no matter what the contents of its body are.

Calling that function without await means it goes onto the micro task queue and you don’t hear from it again until all of the synchronous code has been executed. So more “fire and have the runtime check back later”.

Hope that makes sense.

I also hope it’s correct lol

@boombodies that's what I thought must be the case but I have never done it. For some reason I have always returned things from async rather than do things.

@Crost I find this is the more common use case too.

Sometime though if you have a bunch of non dependant synchronous functions all executed after another you can make them async and execute them concurrently. Or if you have a large array that you need to run larger operations on you can .map them to an async function call and await Promise.all the resulting array of promises so they don’t block each other had they been resolved one at a time.

I’m reading management 101 for dummies and I haven’t seen any of your management skills here

You should always either await an async function or pass a general error handler to "Promise.prototype. catch()" unless the function has a top level try block and/or automated static analysis guarantees that it can never throw, because unhandled promise rejections are a pain in the ass to debug. You ESPECIALLY should await async functions that only throw if their arguments are very stupid, unless all arguments come from the local scope and you can intuitively guarantee their types on the callsite, because unhandled promise rejections don't have a call stack. They're so bad that unless you can prove with mathematical rigor that the function will never throw you should always await it and let the rejection unwind your call stack. Thankfully nowadays most runtimes crash the process on an unhandled promise rejection.

You can also pass the returned promise to some parallelization primitive such as Promise.all or Promise.allSettled. Promise.any works but it's not ideal. Really, the way you choose to handle a rejection is a highly specialized design question, but never ever leave it unhandled unless you like debugging errors whose call stack starts in a function that's neither an event handler nor called from global scope.

Also local variables in async stack frames are freed unless they're upvalues of either a lambda or the later half of the function, so the stack trace you'd end up with probably starts in a call that you know nothing about other than the function. Not the parameters, nor the caller.

Holy crap ... I had to go for two and a half years not using
<? In php cause "that's dangerous"
Also took a year and a half of convincing just to get our code deployment process tested and automated using bamboo. Dude literally would shoot down any idea that he didn't come up with himself and it sucked.