Thread

Go Concurrency Distilled

402 points · 187 comments · chmaynard

voidfunc · 1790483795 · focus · HN ↗
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.
1. za3faran · 1790483914 · focus · HN ↗
  Arguably, Java's virtual (green) threads managed through structured concurrency and futures is a superior approach.
  1. SamInTheShell · 1790484907 · focus · HN ↗
    Depends on what you're solving for. Message passing is fine. That's all channels does.
  2. jatins · 1790490358 · focus · HN ↗
    > superior approach
    superior how -- What does it do better over Go channels in your opinion?
    lenkite · 1790495059 · focus · HN ↗
    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.
    catlifeonmars · 1790498023 · focus · HN ↗
    This is why sync.WaitGroup exists, but you have to manage the lifecycle explicitly, it’s not built into the language.
    cbg0 · 1790498587 · focus · HN ↗
    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.
  3. Mawr · 1790503165 · focus · HN ↗
    Arguably, being 10 years late to the party is pretty bad.
    Just how Go adding generics to the language didn't magically fix the billions lines of non-generic Go code, adding virtual threads to Java didn't update its entire ecosystem to take advantage of them.
    Meanwhile, the entire Go ecosystem from the beginning took advantage of goroutines, so all code you'll ever interact with will have excellent support for them.
    gf000 · 1790505668 · focus · HN ↗
    If you make use of a 30 years of library that does simple blocking IO and you call that library from a virtual thread you literally have non-blocking behavior - so your "didn't update it's entire ecosystem" is plain wrong. It's also just a Thread, so even consuming virtual threads by old libs is just fine.
    Also, what 'party'? There is java, go, Haskell and erlang with anything similar. The majority of programming languages don't have such a feature so it's pretty questionable use of word to "be late".
    joe_mwangi · 1790534774 · focus · HN ↗
    Trust me. That's a common argument used when java introduces new features. Wait you see the same argument once value classes come to jdk 28.
    za3faran · 1790542532 · focus · HN ↗
    I find that very debatable. Spring Boot, for instance, is just one config line away from automatically using virtual threads in its handlers:
    spring.threads.virtual.enabled=true
    We also see library implementations switching to them.

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.