The concurrency complaint is strange, as almost nothing in it is correct.
1. Rust never "course corrected" to implement CSP, and as far as I can tell ESR is making that up.
Rust actually implemented channels and tasks as builtins first, with no mutexes or shared state available--those came later. At some point we saw the opportunity to reduce the complexity of the language and move the language closer to the metal by moving channels and threads to the library instead of keeping them as primitives. Mutexes and reader-writer locks followed a year or two into the language's development--in fact, they were partially implemented on top of channels at first. In fact, the motivation was essentially "hey, look at this neat thing I can do with borrowing: safe mutexes!", not "let's get rid of channels".
2. The idea that channels are going away is also untrue. I've heard a couple of people wish that channels could be removed the standard library and moved to the nursery since they're a fairly complex implementation, and embedded users might want a slim libstd. But nobody has ever floated the idea of channels just vanishing outright in favor of shared state and mutexes: it's absurd. Moreover, the standard library is stable and must be supported going forward, so we can't make that change even if we wanted to.
3. Go has mutexes as well. They're right in the library in the "sync" package. They're fairly idiomatic too: embedding a mutex in your structure as an anonymous field so that your structure can inherit the Lock() method is common.
4. ESR needs to be clear about exactly what defects can arise with mutexes. If he were to enumerate them, he'd find that Rust's type system is carefully designed to avoid them.
A very useful post. Can you answer his complaint about epoll as well (maybe you did already, and I don't know rust will enough to identify your answer).
1. Rust never "course corrected" to implement CSP, and as far as I can tell ESR is making that up.
Rust actually implemented channels and tasks as builtins first, with no mutexes or shared state available--those came later. At some point we saw the opportunity to reduce the complexity of the language and move the language closer to the metal by moving channels and threads to the library instead of keeping them as primitives. Mutexes and reader-writer locks followed a year or two into the language's development--in fact, they were partially implemented on top of channels at first. In fact, the motivation was essentially "hey, look at this neat thing I can do with borrowing: safe mutexes!", not "let's get rid of channels".
2. The idea that channels are going away is also untrue. I've heard a couple of people wish that channels could be removed the standard library and moved to the nursery since they're a fairly complex implementation, and embedded users might want a slim libstd. But nobody has ever floated the idea of channels just vanishing outright in favor of shared state and mutexes: it's absurd. Moreover, the standard library is stable and must be supported going forward, so we can't make that change even if we wanted to.
3. Go has mutexes as well. They're right in the library in the "sync" package. They're fairly idiomatic too: embedding a mutex in your structure as an anonymous field so that your structure can inherit the Lock() method is common.
4. ESR needs to be clear about exactly what defects can arise with mutexes. If he were to enumerate them, he'd find that Rust's type system is carefully designed to avoid them.