> As an aside, if ESR couldn't get Rust's ownership model, I wonder how long it took him to internalize how not to write memory bugs in C?
Rust's type system, like any type system, is limited. It enforces a certain style of safe programming and will reject other styles of safe programming.
The compiler is also not great at explaining why something is wrong. I'm not knocking the compiler writers, because it's a hard problem and they're putting serious effort into it. But from ESR's perspective, he's writing code that is safe (according to a style he's developed over decades of programming) only to have it rejected with an explanation that doesn't make sense. It's frustrating.
There are ways to improve the learning experience. You can improve documentation, improve compiler error messages, and improve the type system itself (e.g. non-lexical lifetimes). The Rust team appears to be taking all of these seriously.
I think the people who make it past the initial frustration are those who believe that it will be worth it. I'm a huge fan of type safety guarantees. I've also followed the development of Rust enough to know that the people making decisions are good at designing languages. So when I'm frustrated, I remind myself that this is probably all worth it.
But reading ESR's write-up, he's clearly not coming from the same place. He believes that Go and Rust both have "strong type systems", which is clearly false. He complains about Rust exposing an unsafe construct like mutexes without realizing that Rust mutexes are much safer than in C. But to be fair, he's also thinking about a specific project that needs an efficient epoll-style mechanism and Rust is just not there quite yet.
Rust's type system, like any type system, is limited. It enforces a certain style of safe programming and will reject other styles of safe programming.
The compiler is also not great at explaining why something is wrong. I'm not knocking the compiler writers, because it's a hard problem and they're putting serious effort into it. But from ESR's perspective, he's writing code that is safe (according to a style he's developed over decades of programming) only to have it rejected with an explanation that doesn't make sense. It's frustrating.
There are ways to improve the learning experience. You can improve documentation, improve compiler error messages, and improve the type system itself (e.g. non-lexical lifetimes). The Rust team appears to be taking all of these seriously.
I think the people who make it past the initial frustration are those who believe that it will be worth it. I'm a huge fan of type safety guarantees. I've also followed the development of Rust enough to know that the people making decisions are good at designing languages. So when I'm frustrated, I remind myself that this is probably all worth it.
But reading ESR's write-up, he's clearly not coming from the same place. He believes that Go and Rust both have "strong type systems", which is clearly false. He complains about Rust exposing an unsafe construct like mutexes without realizing that Rust mutexes are much safer than in C. But to be fair, he's also thinking about a specific project that needs an efficient epoll-style mechanism and Rust is just not there quite yet.