* All variables are expected to be sized. So, learn what's sized and what isn't.
* Understand traits and how they add functionality to types. Have a small dictionary of common ones (From, Into, Debug, etc.)
* Learn how to write blanket implementations for traits. This can make your code lighter-weight. You also learn to start looking for blanket implementations.
* Encapsulate ownership details when possible. I'm not sure about the best way to explain this, but...at a high level it means "structure your types so that you avoid sharing ownership".
As for "encapsulate ownership details". Hard to describe, but...let me point to Tokio [3] again. In Java if you wanted to share an IO reader/writer with two different objects you'd use the same type and pass the same reference to both owners. In Rust, the same idiom would require the wordy use of `Arc<Mutex<Type>>` or `Rc<RefCell<Type>>`. I hope we can both agree that that's frustrating. An alternative (as demonstrated by Tokio's `split` method) is to separate your base type into two other types - reader and writer - that can be owned independently. No more externally-visible ref counting. Of course, this isn't possible in all scenarios: there absolutely are times when you don't have a clean separation of types and have to ref count; but, avoid it if you can.
I learned all of this by poking into libs, asking a ton on the IRC channels (everyone is super friendly) and failing a lot. Any errors are my own. Hope that helps!
[1] https://github.com/tokio-rs/tokio-io/blob/master/src/lib.rs#...
[2] https://doc.rust-lang.org/src/std/error.rs.html#281
[3] https://github.com/tokio-rs/tokio-io/blob/master/src/lib.rs#...
Have you read the book's chapter on error handling?[1] It's being replaced in the second version of the book, but I still plan on maintaining it as a blog post[2]. Any advice you might have to add more of what you want would be helpful. (And I ask this because I tried to attack the "how to and why" angle, so I'm wondering if I got that wrong.)
[1] - https://doc.rust-lang.org/stable/book/error-handling.html
This was my feeling when I got into Ruby on Rails (years too late).
Wonder why the difference?
Have you tried functional programmng? Lisp? Ocaml? The complaints of newbie functional programmers are also nearly the same.
The "struggle" is necessary. If there is no struggle, there is no learning of fundamentally new approaches you are not yet comfortable with.
See it as part of the training regimen that lets people emerge as stronger programmers on the other side.
https://ocaml.org/learn/books.html
https://wiki.haskell.org/Books
It could well be, that these books are written for experienced programmers who don't need basic concepts (control flow, object orientation, etc.) explained. But that was not the point.
The absence of an easy road for these langauges is because they need to teach some powerful abstractions first that have no equivalence in Python, Java or C.
(Which probably means your first project should be something open-source so you can share your code easily)
My time never really allows me to be on IRC regularly. Point being that if you can't get on IRC, I don't think it's necessary.
And honestly, error handling was the most difficult thing to understand, until you start groking why sized types are required as return types from functions and that every function call up the stack requires its callees to compensate for all it's error possibilities.
error_chain! has made this all so much better.
If you are not being hyperbolic then please backup your 90% claim.
Er, well I was also using it as a mousepad for about three years...
I've read some other "modern" books about C like "21st century C" but they are not for people that do not know C and they are not so good for people that know it.
Can you provide any arguments to support what you wrote? What alternative you would propose for learning C?
https://www.amazon.com/Programming-Language-Brian-W-Kernigha...
Read what majority of opinions say. It's really easy to criticize without giving better alternative.
Meaning that many C++ applications, even nowadays, are actually C compiled with C++ compiler (not even classes are used).
So the transition between skill levels is quite gradual.
For me it is hard to tell, because I know the language since the C++ARM days, which means it had a feature size similar to Object Pascal and actually smaller than Ada.
Back then compiler writers even though it was easier to implement Ada compilers than C++ ones.
So slowly we got used to the new features, being discussed in books or programming magazines.
Rust has already reached the point where it leaves the world behind. Only the people who have been there since the early days really understand it, and getting into rust gets harder and harder as time goes on.
Yes, there's some awesome documentation, and the error messaging has gotten a lot better. But the power and flexibility of Rust comes at the cost of it becoming harder and harder to figure out how all the thousands of little pieces are supposed to fit together. What's really needed is a kind of "cookbook" documentation that has things like "How to read a text file with proper error handling" and "what is the proper way to pass certain kinds of data around and why".
Right now there's a lot of "what" documentation going around, but little that discusses the "how to and why".