The way that it explained things made more sense to me and helped me to understand many of the design decisions behind why Rust works the way that it does.
But reading books only takes you so far. You need to write code and read code to understand through experience. I took a C program that I wrote at my job and rewrote it in Rust. It was a revelation: in writing the Rust version I discovered many bugs that were not obvious in the C version simply because of Rust's detailed approach to error handling. The Rust version was much easier to understand and maintain and is the one we use now.
I was originally very skeptical of Rust, but if you write software in C or C++ and then write comparable software in Rust, it makes you want to use Rust every time instead. Rust code helps prevent errors of all types that C and C++ allow. Rust tooling and the ecosystem of crates are so much easier to use.
Here is a quote from "Programming Rust" that I found motivating:
The Rust language makes you a simple promise: if your program passes the compiler’s checks, it is free of undefined behavior. Dangling pointers, double-frees, and null pointer dereferences are all caught at compile time. Array references are secured with a mix of compile-time and run-time checks, so there are no buffer overruns: the Rust equivalent of our unfortunate C program exits safely with an error message.
Further, Rust aims to be both safe and pleasant to use. In order to make stronger guarantees about your program’s behavior, Rust imposes more restrictions on your code than C and C++ do, and these restrictions take practice and experience to get used to. But the language overall is flexible and expressive. This is attested to by the breadth of code written in Rust and the range of application areas to which it is being applied.
In our experience, being able to trust the language to catch more mistakes encourages us to try more ambitious projects. Modifying large, complex programs is less risky when you know that issues of memory management and pointer validity are taken care of. And debugging is much simpler when the potential consequences of a bug don’t include corrupting unrelated parts of your program.
Of course, there are still plenty of bugs that Rust cannot detect. But in practice, taking undefined behavior off the table substantially changes the character of development for the better.
I have a copy of Programming in Rust on my desk! I'm slowly working through it (it's quite the tomb). I have also been reading the 'official' Rust book online (it's lighter and more of an introduction).
I'm a bit more hands-on so I have been doing the reading while doing actual coding. I have built a few web APIs with actix and working through coding exercises (https://rust-exercises.com/100-exercises/).
I feel the biggest issues I'm having are around ownership and lifetimes, especially in a long running process with many pieces (like an API server).
It took me a while to get comfortable with Rust.
I tried reading "The Rust Programming Language" book, but had difficulty with it.
The book that worked for me was "Programming Rust": https://www.oreilly.com/library/view/programming-rust-2nd/97...
The way that it explained things made more sense to me and helped me to understand many of the design decisions behind why Rust works the way that it does.
But reading books only takes you so far. You need to write code and read code to understand through experience. I took a C program that I wrote at my job and rewrote it in Rust. It was a revelation: in writing the Rust version I discovered many bugs that were not obvious in the C version simply because of Rust's detailed approach to error handling. The Rust version was much easier to understand and maintain and is the one we use now.
I was originally very skeptical of Rust, but if you write software in C or C++ and then write comparable software in Rust, it makes you want to use Rust every time instead. Rust code helps prevent errors of all types that C and C++ allow. Rust tooling and the ecosystem of crates are so much easier to use.
Here is a quote from "Programming Rust" that I found motivating:
Thanks.
I have a copy of Programming in Rust on my desk! I'm slowly working through it (it's quite the tomb). I have also been reading the 'official' Rust book online (it's lighter and more of an introduction).
I'm a bit more hands-on so I have been doing the reading while doing actual coding. I have built a few web APIs with actix and working through coding exercises (https://rust-exercises.com/100-exercises/).
I feel the biggest issues I'm having are around ownership and lifetimes, especially in a long running process with many pieces (like an API server).