I have a question, even though this blog post is about Node.js, I have a question about Go.

How can you mimic Promise.all() in Go? What would be equivalent code in Go?

asyncfunctionmain(){// Assume all db calls will return a promiseconstfirstUserPromise=firstDbCall().then((res)=>res);constsecondUserPromise=secondDbCall().then((res)=>res);constthridUserPromise=thridDbCall().then((res)=>res);const[firstUserData,secondUserData,thirdUserData]=awaitPromise.all([firstUserPromise,secondUserPromise,thirdUserPromise]);}

packagemainimport("sync")typehttpPkgstruct{}func(httpPkg)Get(urlstring){}varhttphttpPkgfuncmain(){varwgsync.WaitGroupvarurls=[]string{"http://www.golang.org/","http://www.google.com/","http://www.somestupidname.com/",}for_,url:=rangeurls{// Increment the WaitGroup counter.wg.Add(1)// Launch a goroutine to fetch the URL.gofunc(urlstring){// Decrement the counter when the goroutine completes.deferwg.Done()// Fetch the URL.http.Get(url)}(url)}// Wait for all HTTP fetches to complete.wg.Wait()}

not discussing the way the language handles side-effects (golang is built-in and javascript you need to wrap it in something like shown in this article), my personal experience is: it's just a matter of interface response pattern

i've being using it for node.js, typescript, flowtype, you name it... and it works pretty well, is just another pattern inside your codebase

in your example the error you pass on could be generated by .fetch() or by .json() and it's not going to be clear inside the main function

there is nothing preventing you to massage these responses... you can easily branch it in the catch:

use your imagination, but be consistent! :) ... is rare when we need to have these granular error handling in the front-end... in my perspective, your back-end should be handling it (checking for missing params, not found user, credentials, etc)...

in an node.js/express world, your error middleware would be responsible for these branches and the client response/rejection could be only one!

i've being using it for node.js, typescript, flowtype, you name it... and it works pretty well, is just another pattern inside your codebase

Sure, I'm not against it, it's just that in a way you're limited to your perimeter of code, I wouldn't use it in a third party library. Most JS developers expect failure to be escalated to an exception so that if it's synchronous it can be caught and if it's async it can be handled. If suddenly you start returning two-valued arrays you're changing a silent contract. See how complicated it's going to be to change the way Go error handling is done. And Go is nowhere near as popular as JS.

It's not a bad idea inside an app though, as you say, if it's used consistently.