Nobody forces you to use channels in Go, I use them rather rarely, in 9 out of 10 cases it's to pass around a stop handler for some activity loop. That's where

Nobody forces you to use channels in Go, I use them rather rarely, in 9 out of 10 cases it's to pass around a stop handler for some activity loop. That's where they are quite useful. I think of myself of an older generation so my approach to concurrency is to use locks and fancy data structures and fancy architecture to avoid race conditions. I would suggest looking into how easy it is to write an HTTP handler in Go. That involves plenty of go routines. Each connection is a go routine. Each HTTP request also gets it's own (in HTTP/2 the former and later may not be the same). I don't have to think about the blocking nature of an operation to, for a recent example, fetch and parse a remote webpage, I simply do it. The Go runtime will take care of scheduling the goroutines such that if a new request comes in while I'm a tight loop the HTTP server can continue to handle queries. In JS land however, I can't write tight for loops without potentially blocking up the entire server. You mentioned the solution yourself, hide the async nature of the code. My HTTP code doesn't read like async code until you hit global resources. That's what I essentially want. I do not want to think about async until I need it and when I need it I should be able to pretend it's sync without cognitive overhead; that enables me to efficiently reason about the steps a routine takes before every resource a request uses is released again.