[NightMKoder]

If you’re coming from Go especially, my money would be in a similar vein to http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y... .

That is, why be explicit about async when implicit style code is much easier to read. That said, the answer in this case is simply backwards compatibility - JS already had a concurrency model before async/await came around.

You can also make a explicit is better than implicit argument; it’s mostly personal preference/ideology though. That said, Python has been in a fun land of “rewrite the world” because the async model they chose (async/await) was not backwards compatible to any existing libraries. So now in Python which library you use for e.g. http varies with which concurrency model you use in the rest of your app.

[jd20]

NightMKoder is right on, that article ("What color is your function") sums up exactly how I felt, trying to learn JavaScript after knowing Go. Also, this interview with Node.js creator Ryan Dahl, where he himself admits that Go solves the async programming model much better than JavaScript, I can relate completely to the reasons he gives: https://www.mappingthejourney.com/single-post/2017/08/31/epi...

[jerf]

"You can also make a explicit is better than implicit argument;"

While I'm generally an explicit sort of guy in these contexts, there isn't much that being explicit buys you here, except the ability to write bugs. There's really only one right answer and the compiler is perfectly capable of handling it. In the exceedingly rare cases where you need to override it, you can. Given how exceedingly rare those cases are we're easily in the realm of "use another language" or "fork & hack the runtime" sorts of things.