5 ms·
> using the CSP-like (goroutine/channel) formalism which is easy to reason with I thought it was a seldom mentioned fact in Go that CSP systems are impossible
by hombre_fatal 1y ago
> using the CSP-like (goroutine/channel) formalism which is easy to reason with
I thought it was a seldom mentioned fact in Go that CSP systems are impossible to reason about outside of toy projects so everyone uses mutexes and such for systemic coordination.
I'm not sure I've even seen channels in a production application used for anything more than stopping a goroutine, collecting workgroup results, or something equally localized.
- kbolino 1y agoThere's also atomic operations (sync/atomic) and higher-level abstractions built on atomics and/or mutexes (sempahores, sync.Once, sync.WaitGroup/errgroup.Group, etc.). I've used these and seen them used by others. But yeah, the CSP model is mostly dead. I think the language authors' insistence that goroutines should not be addressable or even preemptible from user code makes this inevitable. Practical Go concurrency owes more to its green threads and colorless functions than its channels.
- diarrhea 1y ago> colorless Functions are colored: those taking context.Context and those who don't. But I agree, this is very faint coloring compared to async implementations. One is free to context.Background() liberally.