promiseに似てるけど、全く違うものはerrgroup.Groupと呼ばれます。これもpromiseなんぞと比べれば
コンテキストなどと組み合わせキャンセルやタイムアウト処理が容易にできますし、実行順の制御や包括した
エラー処理以外にパイプラインまで簡単に拡張できます。

例1：ページをフェッチして全ての処理が終わるまで待つグループ制御（１つでもエラーならエラー処理）
https://pkg.go.dev/golang.org/x/sync/errgroup#example-Group-JustErrors

例2：単純な並列タスクを同期するためのグループ制御
https://pkg.go.dev/golang.org/x/sync/errgroup#example-Group-Parallel

例3：多段ステージを設けたパイプライン処理をグループ制御
https://pkg.go.dev/golang.org/x/sync/errgroup#example-Group-Pipeline

例1、例2はJSでいうPromise.all() のような動きをしますがpromiseなんていう融通の利かない非同期のため
だけの劣った機能より格段にシンプルな仕組みです。
上の例でいえば、並列タスクなどではchannelを使用せず、複数起動された軽量ルーチェンから元ルーチェンへ
results配列の結果を戻していますが、これは並列タスクが一段で終わるからです。
次の（例3の）pipeline処理にあるように、並列と並列が連鎖する多段処理においてはchannelのような
仕組みを使うのがとても合理的です。もちろん、処理の終わりの同期のために、selectによる結果受信待ちは
入りますがこれはデットロックではありません

もともとJSのPromiseがなぜあるかといえば、同じプロセス空間で疑似的な非同期処理による実行制御を行うため
だけの仕組みです。このため、特定の変数（結果を格納する配列や変数）に同時にアクセスされるという考えは
ありませんし、そのような（ロックや待ち）制御は必要ありません。現実に同時に動いていないのですから

隣国のアジア人コミュニティに「ストローマン論法」という言葉を連呼するキチガイ集団がいましたが、本当のバカだった