The main message I got from the Go design is that locking itself is a low-level operation - it's designed to synchronize access to shared memory between two or more concurrent processes on a single CPU.
However, that's not what we should have in mind when designing software. The Unix IPC model of file descriptors combined with select syscall (and its successors) was a powerful abstraction by itself, and Go just brought it to the single-program level - instead of pipes, you have channels, and instead of select syscall you have select{} keyword.
The problem is that we're still stuck, mentally, with the C model of threads and shared memory. You can use Go channels as locks and still write C code dressed up as Go. But in my experience, the most powerful design in Go is separating work into goroutines, each of which does one thing (and does it well :), which communicate via channels to achieve a common goal. Preferably, exposing the interface in a simple way, not requiring the user to be aware of them at all. Sort of like Actor model, but with channels instead of explicit addresses.
As long as I've followed this way of thinking, I've rarely had an issue with deadlocks at all.
Go just shows the case as for rust: the louder you shout safety, the less safety you get.
However, that's not what we should have in mind when designing software. The Unix IPC model of file descriptors combined with select syscall (and its successors) was a powerful abstraction by itself, and Go just brought it to the single-program level - instead of pipes, you have channels, and instead of select syscall you have select{} keyword.
The problem is that we're still stuck, mentally, with the C model of threads and shared memory. You can use Go channels as locks and still write C code dressed up as Go. But in my experience, the most powerful design in Go is separating work into goroutines, each of which does one thing (and does it well :), which communicate via channels to achieve a common goal. Preferably, exposing the interface in a simple way, not requiring the user to be aware of them at all. Sort of like Actor model, but with channels instead of explicit addresses.
As long as I've followed this way of thinking, I've rarely had an issue with deadlocks at all.