A Potential Rust Learning Project Group

This is a good idea. I am curious what target group of people you have in mind when choosing this at an even more detailed level.

Anecdotally, from my experience introducing rust in a team of fairly experienced programmers their backgrounds matter a lot. For example, telling a c++ programmer about traits function calls being roughly the equipment of a virtual function call makes them instantly get it. This isn't true if the same explanation is addressed to a primarily JS developer.

On that note, more experienced programmers did complain a bit about difficulty, but then managed to be productive after 3-4 weeks of head-first diving in. This wasn't necessary true about experienced devs moving to C++ where the learning curve, and more importantly the fatal mistake curve persisted past the 2-3 weeks point, well into 2-3 months of finding the usual c++ gotchas in code review or with address sanitizer. Compared to that, the rust mistakes focus usually perf issues or non-idiomatic constructs, e.g not using and_then, etc.

One area that clearly can benefit from this group's effort is the category of students that may learn C/C++ as one of their first language. It was some time ago for me, but i don't think rust is worse than learning C in that regard as a fist/second year student. The missing bits are proper materials that aren't as widespread.


Multiple people have brought up the issue of tailoring learning for different backgrounds. This is a challenging problem, because if you have N concepts and K backgrounds, then you need N × K tutorials to optimally explain each concept for each background.

Here's one possible approach I've been thinking about. What if you created a dataset of tasks: write a simple web server, data processor, CLI, etc canonical Rust apps. Then implement each task in each language, eg Rust, Python, C++, OCaml, so on. These reference implementations can help programmers who know individual languages/paradigms help transfer knowledge from a representation they understand into Rust.

As an example, I've been building a dataset like this but for data science: https://willcrichton.net/expressiveness-benchmark/

1 Like

I like that idea. My point was more of a suggestion on focusing on students or people where rust is one of the first languages and they are just starting out as the more experienced people will complain but still pick it relatively fast in my experience.

Design some learning material for experienced people, with various references will leave out beginners, whereas designing for beginners will still benefit a bit the more experienced people.


Seems interesting! Personally, I was looking for a safer-than-C++ language for several years before I discovered Rust 2 years ago. I had gone through C++, D, Java, JavaScript (I even wrote my own JS JIT compiler with a special real-time-optimized garbage collector several years ago), C#, Pony, Erlang, and probably some others I forgot. I discarded most of them as not being safe enough, or for having a garbage collector (causes problems with real-time software and writing games). Since I was already familiar with Pony's many different reference capabilities, and I had extensive experience in C++ and low-level programming, I think that made learning Rust easier than average for me.

So, if you do include previously-known programming languages in the survey, I think you should include all the above languages (or at least Pony and the more common ones).

This is absolutely amazing! I will be giving these a read over. We should definitely use these as a basis of understanding for how to continue forward.

I absolutely agree. I do believe we can gather some insights into people's previous learning experiences and collect a sort of "base line" to compare future improvements against. That being said, a survey was picked because it's the easiest way to collect some data. As @Diggsey pointed out, there is the potential for a lot of survivorship bias to creep into this if we're not careful, but I think we can guard against that specifically if we make sure our analysis takes cohorts into account (i.e., a cohort specifically for those who tried and gave up on learning Rust).

We will definitely be exploring this question through many different methodologies including user studies, user journaling, and more. I definitely see this project groups job as establishing a lasting infrastructure for continuing to understand Rust's learnability story. After all, we can get a snapshot of the status quo, but having a picture of how this changes over time is what will be truly helpful.

I completely agree. One of my main goals is cohort analysis to try to understand "learning Rust" not as a monolithic thing but as something different for people with different backgrounds including other languages and experience in programming in general.

Yes, at least at first we would be explicitly focusing on beginner to intermediate Rust learners. There's likely a ton we could do for those who are already experienced in Rust who are learning how to tackle more advanced topics (unsafe is of particular interest to me), but to avoid biting off more than we can chew, I think we'll have to let that wait for a while.

I agree that a big challenge for a survey will be that many people won't be able to articulate what they find difficult about Rust. This is going to be a challenge that I think we can work against with good survey design. I'm certainly not claiming that a survey is the best way to investigate this issue, but I don't think it's useless, and it's the easiest way to collect a large dataset quickly. We will not be stopping at a survey though so we won't be drawing conclusions only from survey data.

Surveying Rust educators is a great idea as well! I think we should definitely add this to the list of things to do.

Next Steps

Thanks everyone for the feedback. I especially appreciate the concerns that a survey is not the best way to collect information. I completely agree, but it is also the easiest to start with. I think we should explicitly outline concerns about surveys and make sure we're explicitly addressing these in our survey design.

With that in my I've started a document with the aim of collaborating on survey design. I look forward to working with you all on this.


3 posts were split to a new topic: Doc comment syntax

The project sounds great :star_struck:

My main remark which is where the current status quo of Rust learning material fails is that, since Rust is a complex different language with new unique idioms, it has indeed a very steep learning curve. This is not a problem per se, but it causes most of the learning material out there to over-simplicate stuff (best example being "&mut ⇔ mutable reference"), leading to mislearning stuff. Granted, this is indeed helpful in the short term for the simple cases, but then there is a whiplash in the mid term, since unlearning is way harder than learning. Similarly, because lifetimes are deemed scary, there aren't that many in-depth explanation of the way they work (where @pretzelhammer's tutorial is a great exception to the rule).

In @Manishearth's terminology, I'd say there is a lot of learning material out there to proactively begin programming at Rust, but when reaching that mid term point, all is left (within the most official sources) is reactive-like material (SO, URLO, Discord, Zulip): the good proactive-learning material is scarce and scrambled among a variety of less well known blog posts. I believe this can be improved :slightly_smiling_face:


I agree 100%. I personally experienced this whiplash while learning Rust and I have seen and still see many beginners go through it as well.

There have been a few Rust language features which were implemented to reduce the verbosity of the language and to also make it more approachable to beginners and while these features have all been very successful in achieving the first goal they've largely backfired in achieving the second goal. Some examples:

  • lifetime elision (in functions, methods, trait objects, closures)
  • type coercions (they happen in many places and in many different ways)
  • auto Sized trait bound on all generic type parameters

These things trip up and confuse beginners all the time, and they're very hard to "see" since they're suppose to be invisible in the first place. Aside from the Rust Reference (which no beginner reads) no official Rust resource really delves into the details of any of these things and beginners are forced to learn about them the hard way: through trial & error and eventually Googling the problem and reading a bunch of random StackOverflow answers, reddit threads, and blog posts until it hopefully starts to make sense.


This certainly seems quite interesting. I've been involved with writing documentation for Tokio, and it would be pretty great to know more about why some people really like our tutorial, and why it doesn't work for others. My main idea for how to improve the situation here is to just write a separate collection of examples in the spirit of Rust by example, but that doesn't really improve the tutorial itself, rather it just adds an alternative.

1 Like

I also agree with this, and think it's important to emphasize the point that "learning materials" here means all official documentation. I.e. some things aren't documented at all, or are only in the text of RFCs, or are only in the PR and FCP threads of RFCs.

I was going to list some concrete examples but decided this isn't really the place for that, but hopefully it is information the group surveys for or otherwise gathers. I will note that I am talking about parts of the language that come up in forums and that most programmers do need to know, not obscure cases.

1 Like

Hi ! A bit late to the party, but I would like to sign up to help @rylev . I've been running pairing sessions introducing people to Rust for a while now, I am happy to share some examples of how different people's learning styles differ and what makes them stuck and what makes them overcome those roadblocks. Is there a good place/meeting to discuss/write those down ?

One thing I haven't heard mention yet (sorry if I missed it) is visibility of existing resources. When I mentioned learnability on Reddit people suggested e.g. tourofrust.com, Rust in Action and cheats.rs. But how do new users discover these?

Creating more learning resources is a great goal (btw, and more videos would be good too) but if they aren't visible to new users then we'll still have a problem.


Another topic to think about: learning cliffs.

In working on Rust, I've seen several instances where an experience forces someone to confront a large set of unfamiliar concepts, and they give up. For example:

  • A person wants to do an ownership-sound action, like taking disjoint mutable slices of an array, or temporarily taking ownership of an &mut value. This is simply impossible without knowing the relevant helpers (Vec::split_at_mut, take_mut), or without implementing it yourself in unsafe code.

  • A person wants to understand why their warp code isn't compiling. They look at the type definition of the combinators, and have no idea what an HList is or how any of this works. Without understanding type-level programming in Rust, they have no idea how to interpret these traits.

Learning cliffs often arise when the details of a system's implementation are needed to understand its interface. For example when the simple ownership rules diverge from the actual borrow checker. Or when a simple mental model of a primitive's type signature diverges from its implementation. Compile-time cliffs are particularly frustrating, because you have code that simply won't compile. You can't look at the output, debug it, or otherwise interact with the compiler.

Helping users understand when they've reached a learning cliff and what to do could be valuable. Eg directing users to better high-level explanations, better in-depth learning materials on system implementation, or better APIs that avoid the issue.


As the other co-author of The Book, I also wanted to add some ideas, thoughts, and feelings.

Overall, I love this idea and think this is important work!

As far as this interacts with The Book, I feel... less excited :slight_smile: I think Steve and I have a really good idea of the rough parts of the book. Fixing them, though, has a few problems: for one, neither of us have much time to give to the book these days. Secondly even if we did have time, the book feels kind of like spaghetti legacy code at this point: whenever we try to fix a problem in one spot, we inevitably cause problems in other spots because of how the topics intertwine, the examples build on each other, and so forth. Steve even started experimenting with a new book at one point (sorry @steveklabnik , I can't find a link to it right now). Prepping large edits for being incorporated into the print version is also a LOT of work, and not incorporating them causes confusion about why the online and print versions are different.

All this is to say, please don't generate more feedback for Steve and I, please. In fact, the issues and PRs on the book might be great data for you, but we really don't need any more. And if the book is no longer meeting learners' needs, or not meeting all learners' needs, please consider creating new resources, not modifying the existing one. I often tell folks how glad I am that the O'Reilly Programming Rust book, and @timClicks' book, and other books, exist, because they're all different and that means The Book doesn't have to try to be those books too.

Jake and I also made the Rust in Motion video series to address the problem we kept seeing of people who are used to being able to pick up new programming languages by just diving in, and they hit a huge brick wall with Rust. We focused it on the parts of Rust that are most different from other languages (ownership/borrowing, error handling, lifetimes) so that you have enough knowledge of the concepts to get back to however you usually learn languages.

@shepmaster has also done a number of trainings and is also prolific on stack overflow, so he might have some useful thoughts as well.


I completely agree with this: it will be literally impossible to have the one book that rules guides them all; each book should have a somewhat opinionated stance and teaching style, so that it will best fit some people, whereas other people will prefer different learning materials.

For instance, regarding my previous post, I do think that it is important to have a learning resource that is as beginner friendly as possible! That's almost the most needed learning resource in any topic. But now that we have it, I do think it is time we enhance the official learning resources out there with more precise (and thus maybe more intimidating) ones.

  • I, for instance, personally plan to undertake, hopefully soon enough, a complete guide on macros: it shall act as a complementary view w.r.t. the Little Book of Macros, and from there include procedural macros, for which there is sparse guided documentation.

I feel I struggle to learn and comprehend Rust because of lack language understanding. Tecnical english can be hard to read at times when you dont have it as main language or are not educated well enough. To aid this I think animations, illustrations and graphical figures to represent and visualize concrete and abstract consepts would be a tremendous help. A lot of people learn better by visual input rather than reading to comprehend stuff. Visuals are universal, written language is not. Visuals should definetely be a part of the Rust book.

At the same time I also miss a simple way to make graphical interfaces. Some cool stuff is on with Bevy for example. I really think more people should involve them self in that with the aim to make a cross platform lib built into the language.

A lot of people also find it more rewarding to see a graphical result of their work if it is easy to do it.

I had a great time learning about programming using Flowstone, but it is purely 32bit Windows and not really a programming language. It is graphical/visual programming with the ability to use premade blocks/items/functions/whatever and the ability to make own code in a C like language, ASM and Ruby. But you can make pretty much anything with it. It is in my opinion very easy to learn. And the results comes very quickly. I would love to se something like Flowstone based on Rust, to develop in Rust. Have a look at the Flowstone manual. Or the component refence.


But for a start please make things more visual orientated in all aspects, especially in the Rust book for learing this cool language. <3

This is a great point that I'd like to make clearer: We only aim to provide feedback where it is wanted and needed. I apologize for using the book as example (even after Steve gave similar albeit a little less on the nose feedback). I certainly have 0 interest in causing more work with no gain for anyone. :grinning:

I also have no interest in prescribing fixes to specific learning materials but rather to provide evidence about how groups of people learn Rust in various settings. We may actively ask learning material creators if they want to work with us on gathering this evidence, but we won't spam folks with specific issues about the evidence we gather.


My plan for the start of the new year with regards to this effort:

  • Continue gathering feedback especially from those on the lang and core teams. My not-so-secret hope for this effort is that it eventually gets folded into other project processes and helps inform how Rust evolves in the future. This requires at the very least an interest from those in the lang, core, and other teams in trialing this type of effort.
  • Work (with others) on creating a fact finding mission on the status quo of learning Rust in 2021. It's clear that many people have ideas of what challenges folks face when learning Rust, but I'd like to try to see if we can more easily quantify this if only to have comparison points we can measure against in the future. This will most likely involve a survey, but as many have pointed out, surveys are far from perfect, so we'll have to brainstorm on how to supplement survey data.
  • Create a repository where information on how Rust is learned is gathered. This is perhaps a less clear goal as of now, but I'd like to try to gather the institutional knowledge folks like @carols10cents, @steveklabnik, @pretzelhammer, myself, and others as Rust educators have about challenges with learning Rust into a place that can be more easily understood, quantified, and acted upon. What this actually means in practice, I'm not sure, but it will start with housing the results of the learning survey as well as existing studies like the ones linked to by @willcrichton.

If you're forming a working group for this, I'm interested in joining :slight_smile: I'm not sure the process for doing that, though.

1 Like

First of all, I appreciate the desire to open such a group.

I have some feedback to this, some pretty fundamental. My core criticisms:

  1. The concept of "learnability" is ill-defined and generally one I've frequently criticised here. This would make the first effort of the group a definition of its topic.
  2. The artifacts of this group are rather unclear, it explicitly avoids producing content. I think a different scope would enable a better artifact.
  3. The group wants to provide output to educators, but the only group directly mentioned in the "Call To Participation" are data scientists.
  4. It focuses on inspecting the language rather than the teaching practice.
  5. I recommend to not lean on the concept of a "Learning Style", which has not held in multiple studies in the last decades(!). "Learning Styles" are often a proxy for certain things missing, e.g. we have almost no visual tools for explaining memory - which might be flaw for everyone that some attribute to their "style", while it's actually useful to many.

While I appreciate the desire for a user study, the subject matter, especially around programming languages is what I call a research problem[1], which does not seem to be a good first task for a group. It is very hard to assess and de-bias such a dataset. Self-Reporting is also highly problematic for detailed conclusions.

I think making the language "better learnable" is a good desire, but there's lower hanging fruit. My favorite example here is the turbofish-Operator: while it is a wart in the language and might trip people, it has no interdependence with other parts of the language and can just be learned as an odd fact. Science Educators teach such facts easily every day. The other side is that Rust has a number of fundamental concepts that are very new to people - for example: is Ownership or Borrowing the dominant concept in Rust? How do we get people to model with Ownership quick?

Honestly speaking, on almost every RFC where "learnability" ended up the final argument, my assessment as an educator was that the change was not worth the effort and cost of backwards compatibility.

We do, however, have a pool of knowledge already within the Rust project even: by speaking directly to educators and collecting practices. We do have people that taught Rust over the last 5 years, in settings from small to large groups. The have already tested many approaches. I think it's a way faster path to success for such a group to start speaking directly to or build it out of those people and have them condense their experiences into supplement material. Rather than changing "the book", producing co-material for those interested in teaching would be a huge boost to the ecosystem. Also, it can provide a number of sources to those with the desire to create courses.

This has multiple advantages:

a) It draws educators into our project and gives them a place. This forum can also be used for feedback.

b) It makes the group operate on what is currently available rather then having the group set up a foundation first.

c) It is common practice in many organisations that revolve around training/teaching, e.g. every sports association as a trainers forum rather than a "what do we change about the sport to make it easier?".

Currently, the effort of producing teaching Rust means reinventing the world every time - addressing this may yield much better results much faster.

[1]: In that academia is still running studies for assessing those topics.