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.
But locks and shared memory aren't necessary for deadlock. You can easily deadlock with high level concepts. For example you can deadlock reading from channels, or the classic deadlock of waiting for a process to end before reading its output (which works if the output is small!).
There are definitely coding patterns that can help with deadlocks, like unbounded queues and avoiding cases where you are waiting on events from multiple sources in one task. But I haven't heard of a comprehensive way to solve them completely.
After that wild ride into concurrency unsafety you might enjoy a concurrency safe language without any locks and blocking IO: pony
Go just shows the case as for rust: the louder you shout safety, the less safety you get.
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.
But locks and shared memory aren't necessary for deadlock. You can easily deadlock with high level concepts. For example you can deadlock reading from channels, or the classic deadlock of waiting for a process to end before reading its output (which works if the output is small!).
There are definitely coding patterns that can help with deadlocks, like unbounded queues and avoiding cases where you are waiting on events from multiple sources in one task. But I haven't heard of a comprehensive way to solve them completely.
You don't really need any exotic OO GCed language to enjoy concurrency safety without deadlocks.
Indeed. A concurrency safe language doesnt need OO. It just needs to avoid POSIX.