How to become a Rust ninja? 🥷

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 :sweat_smile:. 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.)


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.

Hope you stick around!


In my opinion, there is no substitute for writing a high volume of code.

  1. Type out all the examples in Introduction - Rust By Example

  2. Work on whatever you are passionate about, where some external goal will provide motivation to work through all the rustc compiler errors.

  3. Write lots of code. When you run into an issue you can't solve, reduce it to a minimal example and post here.


Yeah, you're right, the problem is that I am afraid to provide wrong or inexact answers, but you're right, trying to answer is a good exercise.

:heart_eyes: :dizzy_face: :exploding_head:

Thank you so much for your reply! That's gold! I will take lot of time to go through all those stuff, but I will give a try!

Again... Thank you!

1 Like

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.

Anyway, here goes:

If others have lists, I'd be interested in seeing them too!


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.


I have just read Common Rust lifetime misconceptions (from your suggestions list).

Kudos to the authors and to you for linking it here! :clap: :clap: :clap:

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 :blush:). 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.

I wonder if one can side step the curation / "politics" issue by having a rust-wiki-cookbook, basically a community created Vec<(Question, Vec<Solution>)> , where Solution are links to Rust-playground snippets.

Thus, instead of endorsing articles, it's just saying: these are valid problems, and here is a community donated list of solutions.

1 Like

What about Table of Contents - Rust Cookbook

1 Like

41 posts were split to a new topic: Using optional callbacks in Rust

The Rust Cookbook is fantastic; the only thing that can make it better, in this context, would be making it wiki-style. I would suspect wiki-style cookbook would (1) have a few more entries and (2) likely have new entries add daily. [Just imagine if every day, the most useful response on this forum was converted into a wiki/cookbook style q/a and added].


This is true but also it's complicated! For example, the first edition of the book had two major sections that were taken from community blog posts, namely @Manishearth's Wrapper Types in Rust: Choosing Your Guarantees - In Pursuit of Laziness (which was Choosing your Guarantees) and @BurntSushi's Error Handling in Rust - Andrew Gallant's Blog (which was Error Handling)

We could in theory do a similar thing for a post like this. But practically, these chapters were removed eventually, not because they're not awesome, but because they don't quite fit with the rest of the book: they're written by completely different authors as standalone texts, so that makes perfect sense!

We could adapt that text for the book, but that also has some big issues. Namely, the book is already very large. Adding even more stuff to it has some downsides, as well as upsides. There are tons and tons of things that go into learning Rust, one book cannot be everything to everyone.

So, @killkrt, I am glad you liked the article, it's a great one! But it is not going to be put into the book.


Interesting question. I've allowed myself to distance a bit from Rust'ing around for the last several months, as slightly more higher-level projects, such as an app I'm currently building, in Flutter, which a Dart framework, have sucked all of my attention, but I still love Rust. The safety, the speed of nearly raw-metal execution, along with higher level constructs baked directly into the language - all represent an insanely powerful combination.

With that said, as of today it still isn't a language to be used everywhere - I certainly wouldn't use to build any kind of app for a mobile device, that's for sure. And as much as the community might like to tell everyone to "just build it in Rust" would like to see the rate of adoption of their favorite tool grow over time, there are a lot of other languages that are just good enough for their particular use case.

If you need to rapidly test a web idea you have, it's much easier to go for a Node backend + some JS framework than try to compile all of your favorite Rust constructs into a WASM binary to link to in your web page, before serving it with Actix Web - the first compilation process on its own will take you much longer than initialization of a simple "hello app" in React or Angular.

If you're looking to build games - there is Unity. Tons of community packages available, tons of tutorials - you'll be starting on a solid foundation of people that have "been there, done that", and you won't have to concern yourself with all the nooks and crannies of semi-esoteric lifetime-annotated dynamically generated functions, bound by traits you never imagined would be important for the functions that you're putting together.

Still, going back to your question - about becoming a Rust'inja (can we shorten Rust Ninja to that?) and really mastering what the language has to offer. This just hit me earlier. If you're coming from any other language, other than C/C++, you're most likely to think about any "data" you work with as an "object". It's a "thing" that has some "properties" and that can "do" something with its "methods". Rust takes this notion of yours, looks at it, looks at you, smirks, slaps you across the face with it and throws it out of your freaking window.

Rust doesn't think in "objects". It doesn't care about them, their properties or their methods.

Rust thinks in contracts and expectations. Some of which are defined by you, and most of which were defined before you, by a bunch of a very bright folks who have spent 10s of years trying to create solid software which wouldn't crash when they'd put in front of their users, failing over and over, before deciding there is a better way.

A way that involves restricting you as much as possible from shooting yourself in the foot, while providing you with the same power you have when coding in C++, including managing your memory explicitly, allocating and deallocating it as needed - which is where most of the problems that new people have stem from. With great power comes great responsibility - and Rust tells you exactly what those responsibilities are. Whether you like it or not.

All the things you've listed in your post are the examples of these contracts and expectations. Subtypes, variance, traits, lifetimes, implementations, proper iterations - all represent the different expectations that Rust compiler expects you to meet before it ever thinks about compiling and running your code.

Some of them are straightforward. You have a Struct with typed fields, which you pass as a reference to a function for it to print some data you have there. Simple enough. Now try to think about how you'd implement an asynchronous stream of data, from scratch - starting from a simple:

fn main() {
    println!("Hello World!");

Would you even know where to start? Some people do - and they've created a ton of libraries for you to use. They followed Rust's contracts perfectly (otherwise it wouldn't compile). And now you're expected to follow those contracts to the letter yourself. Why? Because otherwise your program will crash and burn, and you will crash and burn with it - and the whole world will crash and burn around you, and you will be held responsible for it, even though you'll be dead by that point. Rust puts restraints on you to make sure that doesn't happen - as long as you stay out of the Unsafe world. And given how insanely hard it is to wrap your head around the usual expectations Rust places on you - it's quite expected that by the time you get into the prohibited land you'll be more than able to survive there on your own.

In terms of the training path, struggles and projects. The best training path is the one that is meaningful. Decide what you're going to focus on. If it's game design, start with Unity - by the time you master it, you're most likely going to be able to implement the basics in any language, including Rust. Web development? Node JS. Once you've figured out (well, really well) the lower-level details, you'll be ready to tackle Rust's "zero compromise" approach to server-side part of the programming world.

Systems programming or embedded devices, on the other hand? Well then, Rust can be your best teacher here indeed. But the choice remains up to you - decide what you'll be working on, start tackling that projects and master the concepts that you need to master on your way there. You'll soon understand what those "?Sized" - things are and why they need to be specified at times. It'll become obvious where should those "Sync + Send" go and why the lifetimes can help you out.

Struggles are normal. Meaningless struggles that you don't need - aren't. Pick your projects according to what you want to accomplish in the end - and gradually move there. Unless you have a ton of free time at hand and the best way you can think of spending it is by mastering the Rust-speak. In that case, just pick a project at random and start squeezing all of the things you've listed in your post, along with all the Nomicon info, along with random pieces of code from Tokio, along with random low-level libraries you find on or - as long as they seem interesting.

Be ready to bang your head against the table for many days, weeks, perhaps even in a month in a row until you finally reach enlightenment. Trial and error is an essential learning tool - no one can learn the material you're learning for you, and the best way to master anything is by practicing putting it to a good use. And should you get stuck - just ask around here. As long as the question is not too long, pertinent to one particular concept and respectful - people here are more than willing to help.

P.S. Just don't expect any emojis in the answers. Rust masters are stern, concise and direct. Unless there's an opportunity to kindly tell someone that they're a noob - no one will miss that chance.

P.P.S. That was a joke - although I do believe that being a bit less strict with punctuation and using at least some smiling faces or emojis will only benefit Rust's adoption, especially among beginners


Thank you for your reply!

I can see your point, I was not thinking about publishing issues, you're right!
Maybe stuff like that could be explained in an advanced edition or maybe a rusty version of a well known C++ book, I mean something like Effective Rust :relaxed:

Anyway it would be great that the next release of the book could include also an appendix with further reading references (I mean list of selected articles, repositories, blog posts), or maybe mentioning which topics are not covered, in order that readers could be aware of what is missing. Just a suggestion... Not sure that makes sense.

I personally am quite excited for "Rust for Rustaceans" as that sort of second book.


I personally am quite excited for "Rust for Rustaceans" as that sort of second book.

I'll second this - it's been great in Early Access, and I'm sure it'll keep getting better. My personal voyage lately has been focusing on learning the Rust architectural idioms (aka patterns) that don't come naturally to me coming from OO programming. All of the resources and ideas above seem really good for that, but I'll also put in a pitch for the Rust Patterns git book. It's still a work in progress (TODOs sprinkled around), but what's there has been really insightful and helpful for me.


This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.