I am considering myself a newbie or maybe a just little expert than a newbie even if I am buzzing around Rust since years, but I've always used it just to make little experiments, exercises and little stuff.
Lastly I've decided to work on a little game just to get more into Rust and while posting some questions here (BTW thank you for your great support and patience ) I have realized that there are lot of important concepts/language features in Rust that I was completely missing, such as:
Subtyping and variance
dyn Trait is a concrete type
for<'a>
impl Trait
T: 'a
Difference between subtype and implementors
Returning an iterator in a proper way
Anonymous lifetime
...
This kind of things are not explained (or even mentioned) in any books that I read, and I am trying to find some good documents explaining in a clear way, but I am struggling to find them.
I think Nomicon is maybe too advanced for some topics for me, I mean it takes for granted that the reader has lot of experience and that's not my case.
So I was wondering which resource (book, posts, ...) or maybe training path you would suggest in order to really understand how Rust works and be capable to build a big project without struggling each minute to get why compiler complains about on every two lines of code (and avoiding trial-and-error approach).
The nomicon and jonhoo also have chapters/videos on other topics, which you may also find interesting. I wouldn't be scared about reading the nomicon, though some chapters are better than others.
Besides that, consider if you are trying to complicate your project more than need be. For example, a Rust application very rarely needs to talk about lifetimes, and if there are lifetimes all over your code, you are probably making your life harder than need be. Libraries do use lifetimes a bit more often, but even then their use rarely needs to do anything complicated with them.
I don’t think that’s true. I had no problem reading the nomicon almost immediately after the rust book when first learning the language.
Also if you’re after an even more complete understanding of the language, browsing through the Reference is often very useful. And if only to get an actually (almost) complete picture of what language features there are. E.g. having looked at the formal syntax of the Rust language at some point gives you certainty that there isn’t going to be a program around the corner with keywords or other syntax that you haven’t ever seen yet.
And the converse is true, too: it can be immensely helpful to read other people's real-world code. I for example rarely browse the reference just for fun; I learned about most of the advanced features of the language by seeing them used in the wild.
To be honest my idea of developing a game with Rust is quite recurring in my mind, but I never tried for real.
Maybe I am taking the Liskov substitution principle too seriously and I am abusing/overusing of traits and that is driving me in some darker Rust ravines
Anyway I think it is always better to know all features and corner cases of a language in order to understand how to optimize design and implementation, especially with Rust that has a very picky (and that's a good thing) compiler.
That's a good point, but maybe it's not working very well with me, I prefer (it's just my method/approach) to study in structured way.
Anyway you're right, reading, analyzing real code is a good practical and effective way to improve knowledge of a language.
I was making some exercises on Codewars, but they are maybe more oriented in improving problem solving than learning advanced language features (as far as I saw).
Overusing traits is definitely a way people get in to trouble.
When it comes to game development, the truth is that games are a difficult type of project in Rust. I recommend this talk if you are interested in that topic.
I learned about most of the topics you list by reading posts on this forum (and eventually writing my own). I'm not sure how to turn that into a structured course of study, though.
If I hit a specific area to deep-dive on, I often end up in the RFCs. They're not organized like a book and some later ones override earlier ones (which aren't consistently updated to point to the newer ones), so it is a more work. You also might have to go browse the PR and tracking issue to get the full picture, to boot. (In fact, always check the tracking issue to see if it's actually stable yet.) But sadly, there are a number of advanced topics where the only adequate documentation I'm aware of are the RFCs.
Another place, if there happens to be a post or series about it, is Niko's blog (Baby Steps). A lot of "big change" ideas start there, including ones that haven't landed yet but are expected to (Polonius, Chalk). Given when 1.0 came out (with it's backwards compatibility guarantees), most posts since 2015 should still be relevant. Even the earlier ones may be indications of Rust's future.
(Side note: Anyone know how to get a single list of posts out of the new format, like it used to be? An RSS URL maybe? Clicking through 20 pages excerpts is much less reference-happy.)
After that I typically spend some time writing toy programs in the playground, if applicable.
Here are a few links I've found fruitful. OK, a lot of links -- I decided I'd find this useful enough for myself that I just looked through the RFC list and Niko's blog for anything related to your list . The list is something you'd want to cherry pick for your current interest, not something to tackle on one go. Most advanced topics I have to revisit a few times, personally.
(Note: dyn Trait is relatively new, so in a lot of these you'll just see "trait object" and Trait. Also, in the older pre-1.0 ones, you may see Box<T> written as ~T.)
Anonymous (infered) lifeteimes, T: 'a and dyn Trait + 'a
This forum post is great at explaining/exploring the interaction of unsized coercion and dyn Trait's lifetime. In short the coercion can take effect before invariance, which can be unintuitive.
Which links to some issues and posts that highlight a current pitfall of impl Trait / existential lifetimes when compared to dyn Traits type erasure and lifetime bound)
Understanding this requires understanding a lot about both dyn and TAIT, IMO
Advanced(?) lifetimes and ownership
Non-lexical Lifetimes (NLL)
(This is what we have now, lifetimes used to be lexically scoped)
And just to jump on the boat: participating in this forum is also what led me to a lot of the topics above. For me the first level is finding something that works for someone's problem, the next level is finding a reference explaining why things work that way, and the further levels are actually internalizing and understanding the advanced-to-me topic. I also bookmark great posts by others for future reference or to circle back to when I'm interested in tackling a new topic.
I intended to maintain links to some brilliantly clear and helpful posts here. Some in reply to my own questions, many not. Sadly somehow I did not do it.
Perhaps you could post your "best of" bookmarks here?
Sure. Many are recent, as I didn't start doing this as long ago as I now wish. Some are my own, which I keep not out of arrogance, but because they're basically my Cliffs notes. I'll try to give credit when they're based on other people's posts. There may be a repeat or two from above.
You can focus on questions that feel like you can answer them accurately, or you can clearly indicate that you aren't 100% certain yourself. Often it's the questions where you know the answer roughly, but need to dig just a little bit deeper to get things written down properly and consistently that improve your own understanding of things, too.
Answering questions can force you to do a more narrow and focused search online for relevant explanatory material or reference material yourself, sometimes you'll discover new sources of knowledge yourself this way, where someone's question only was the source of new search terms. (And sometimes, trying to answer a question may not lead you to an answer for that question but leads you to learn about a mostly unrelated, yet new or unfamiliar to you topic.)
If it's about digging up tutorials, even with a rough understanding of the topic, you can often judge the quality of tutorials / blog posts, etc. better than the Rust newcomer that's asking a question. Then you can link a good one you found. Or you can help because you at least know the proper keywords to search for. While reading / evaluating existing tutorials, you're inevitably deepening your own knowledge, too.
Kudos to the authors and to you for linking it here!
In my opinion articles like that should be inserted in the official Rust book, they are very precious and well made! I remember that in past survey lot of people asked for improvement of the learning curve, IMHO including such kind of clarification in the official documentation (maybe as appendix) could help a lot of people (like me ). I don't know who is following documentation topics this day, I remember that @steveklabnik was involved in the official book, so he could be interested in this topic.
I think having the language's official guide endorse external work can be a bit hard politically, so they've chosen to stay out of it. That's why you'll hardly ever see crate recommendations in The Book or the standard library docs.
For example, we can't accept every article written about Rust so we need to curate the list, but then how do you set the standards? Who chooses what is "acceptable" and what isn't? What if the author works at a big tech company or the article is from a company's developer blog?
Instead, I'd probably add those resources to an unofficial list, maybe Awesome Rust.
even if I am buzzing around Rust since years, but I've always used it just to make little experiments, exercises and little stuff.
and patience 
) I have realized that there are lot of important concepts/language features in Rust that I was completely missing, such as:
(and avoiding trial-and-error approach).
. The list is something you'd want to cherry pick for your current interest, not something to tackle on one go. Most advanced topics I have to revisit a few times, personally.
