Superior in ergonomics - launching several async tasks and combining their results via futures is is much easier compared in Java compared to to Go's low-level, primitive way of doing things. No need to explicitly create channels and wait on them. Go doesn't expose Go-routines as a type and hence you are brow-beaten into laboriously using channels even when there is no real need to do so. I guess this could be all sorted out if the Go stdlib offered some convenient structured concurrency packges.
Superior in ergonomics - launching several async tasks and combining their results via futures is is much easier compared in Java compared to to Go's low-level, primitive way of doing things. No need to explicitly create channels and wait on them. Go doesn't expose Go-routines as a type and hence you are brow-beaten into laboriously using channels even when there is no real need to do so. I guess this could be all sorted out if the Go stdlib offered some convenient structured concurrency packges.
While stdlib doesn't handle this, there are libraries that can support your use case https://github.com/jizhuozhi/go-future
If you only need to launch work and wait for completion, Go 1.25 has sync.WaitGroup.Go -> wg.Go(f) -> by wg.Wait(). No channels like the page says.
This is why sync.WaitGroup exists, but you have to manage the lifecycle explicitly, it’s not built into the language.