Ive been writing Go for over a decade and I still feel like I never quite "got" channels. Every time I use them I need to go consult the manual, and none of the patterns feel obvious which is weird considering the rest of the language feels very obvious.
Too many years of Java and managing Threads and Runnables probably rotted my brain.
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 <a href="https://github.com/jizhuozhi/go-future" rel="nofollow">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.
voidfunc · · focus · HN ↗
Too many years of Java and managing Threads and Runnables probably rotted my brain.
za3faran · · focus · HN ↗
jatins · · focus · HN ↗
superior how -- What does it do better over Go channels in your opinion?
lenkite · · focus · HN ↗
cbg0 · · focus · HN ↗
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.