I very much disagree, though, about what you said about mutexes and channels. Channels are by far the most idiomatic way to transfer data in a concurrent model. Timeouts, worker patterns, and program architecture are much much more idiomatic and less error-prone when using channels.

Mutexes can be used properly, but it's rare that there's a situation where using a mutex would be better than using a channel. When I was first learning Go in 2017, I had to emerge from the shell of using mutexes that I had entered after working in other languages. After switching to predominantly channel-based communication, I found that my architecture became much less error-prone, and that things just worked. Prior to that, I would spend tons of time trying to figure out the exact situation that had put me in a deadlock, where several goroutines were waiting for a mutex to be unlocked that never was, or where a goroutine was trying to unlock an already unlocked mutex.