A Potential Rust Learning Project Group

announcements
1

We, @rylev and @ekuber (with @nikomatsakis as lang team liaison), propose an initiative to better understand how people learn Rust with the goal of helping the Rust project continue to make learning the language and core tooling easier.

This is an open call for feedback on this idea.

Motivation

Rust is well known for its somewhat steep learning curve. In the latest Rust annual survey, many pointed out that making Rust easier to learn would directly help promote the adoption of the language.

Over time, Rust has become easier to learn thanks to initiatives like the Rust book, friendly error messages, non-lexical lifetimes, and more. However, we believe it is time for there to be a concentrated effort in understanding how people learn Rust in order to continue this progress.

Charter and Goals

The project group's charter is simple: help make Rust easier to learn.

The Rust learning project group's initial goal is to better understand how Rust is being learned including common pitfalls and areas of particular confusion in order to provide information to the Rust community for how to improve Rust's learnability.

We hope the information obtained by the project group to be useful to many different parties including the lang and compiler teams to improve new and existing features and diagnostics as well as to Rust educators across the Rust community.

The project group will not engage directly in creation of learning content. Instead, the project group hopes to assist already ongoing efforts within the community.

We expect to eventually propose the project group as a lang team project, but we are open to feedback on the best home for it.

First Activity

The first concrete activity to be done by the project group will be to conduct a Rust learnability survey to better understand the status quo.

Questions We Hope to Answer

The survey will aim to shed light on the following questions (note: these are not the questions that will be asked, rather the ones we hope the data helps us answer):

  • Roughly how difficult is it to learn Rust compared to other languages?
    • How much "effort" does it take to learn Rust?
    • What technical backgrounds make it easier or harder to learn Rust?
    • What is the nature of Rust's learning curve? Is it short and steep or long and gradual?
    • How do people define being "competent" in Rust? How does this differ from other languages? Do people generally over or under estimate their abilities in Rust?
  • How does learning Rust differ for those with different learning styles?
    • How well does the Rust project's and Rust communities learning materials server those with different learning styles?
  • What topics are the most difficult for people to understand?
    • When in the learning process do people typically get tripped up on these topics and what exactly seems to trip them up the most?
    • For those who know feel confident in these topics, what helped them gain that confidence?
    • What patterns from other languages do people typically try in Rust that lead them down a bad path?
  • What resources do people typically use to learn Rust and in what order?
    • Are there any best practices for teaching certain topics?
  • What error messages and other diagnostics are good for advanced users but poor for new learners and vice versa?

Call for participation

Assuming the community and the Rust project think this is a good idea, we would like to invite others to work with us. If you would like to participate, please let us know.

First, we are looking for feedback and participation from any interested members of any team within the Rust project. We hope that this effort can shed light on how people learn to use Rust holistically from the compiler and language to core tooling like Cargo and rustdoc.

We are also looking for people with data science backgrounds who will be able to assist us in creating and analyzing the survey.

Future Possibilities

For now, we aim to keep the goal of the project group simple, focusing on better understanding the status quo of Rust's learnability story. Further activities in pursuit of this goal may include:

  • Learnability studies where we actively monitor people's unguided learning experiences.
  • Guided teaching sessions which aim to teach Rust in controlled ways to gauge effectiveness.

If the first activity of this project group proves to be sustainable and successful, we may want to consider making this an official working group (potentially under the lang team, though this is an open question). This would entail growing the goals of the project group to include any of the following:

  • helping the project identify what specific areas are under documented or documented in a less than ideal way.
  • helping eliminate common "papercuts" from certain usage scenarios.
  • explicitly assisting initiatives that produce official learning material such as the book and Rust by Example. Note: this will not be through producing content but by:
    • helping gather and process feedback
    • producing user study data which could help better tailor the material to learners
    • recruiting help to produce content should the specific project desire it
  • helping fine tune processes such as the RFC so that learnability is appropriately considered.
45 Likes
2

As someone who has a reactive learning style, is largely self taught not by books but by "learning by doing", and has mentored multiple people like me, I'm very much for this!

I do think that quite often we've ended up structuring "how do we teach this" as "we'll document it in the book / documentation", which is a disservice to the large chunk of people who do not approach learning this way. Rust's focus on diagnostics (in a large part due to @ekuber's tireless efforts!) on the other hand is exactly the kind of thing that helps here, and I'm excited to see more holistic approaches that ensure both kinds of learning are up to scratch.

This may be a bit of a tangent, but I'm reminded of Nell Waliczek's "pit of success" vs "pit of failure" terminology when approaching API and system design in my work with her in the W3C. It's quite easy for a design choice to be the kind that, while very good for people who understand it, has a tendency to drive people into a bad mental model, i.e., a "pit of failure". On the other hand, you can try and construct a system which attracts people towards the correct mental model and is resistant to them picking up the wrong mental model -- i.e. a "pit of success".

It would be nice for the project to have more space for pedagogical thinking; and be able to instil such thinking in the initiatives the project undertakes.

19 Likes
3

This is a great idea, and I'd love to participate. For reference, I'm a PhD student at Stanford working on the intersection of programming languages and cognitive science. It's my goal to understand how programmers learn and use programming languages, especially ones like Rust.

First, it would be good to collect prior work into Rust's learnability. I've worked on this a fair bit myself:

Second, we should think critically about methodologies for identifying learning barriers. I know surveys are the default method for the Rust community. But there are more effective methodologies for generating useful insight into issues of HCI and pedagogy (see Table 1 of this paper for a good list).

For example, user studies. A few weeks ago, I ran a user study where I asked a few Rustaceans who didn't know warp (marketed as "super-easy") to make a 10-LOC change to one of the examples. I saw even veteran Rust users struggle to find relevant examples and make use of documentation. Inspired by that user study, we developed a rustdoc extension to link examples within documentation that we're looking to merge soon. I honestly don't believe anyone would write on a survey "I wish rustdoc linked to the examples/ directory", but that kind of insight is often more apparent by careful observation of users at work.

The point is: how you study learnability is quite important. And as a project group, we have the opportunity to create infrastructure to facilitate methods of inquiry. For example, imagine if we maintained a mailing list of people willing to participate in user studies. This would make it easier to quickly find participants, which is often a big non-starter unless you have an existing network of Rustaceans.

32 Likes
4

I think it's worth mentioning that as a co-author of the book, I feel this way too.

12 Likes
5

This would be awesome! Rust does have a steep learning curve. Having a steep learning curve is only bad if there is no one there to help. Ironically, I took on the challenge of learning Rust just on the fact that it was difficult.

I will answer some questions based own my experience. I had two attempts in 2020 at learning Rust, and it was not until the second attempt that I started to get it. Thanks to videos by @rylev and @jonhoo, The Book, and other materials. I still do not understand everything, nor do I think I need to understand everything and might even be unsafe to do so. In my opinion I do not think there will be a one solution fits them all based on how we learn, experiences and current programming environment. I have over 20 years of programming with various languages and environments. Currently .NET and C#. With that experience I still could not get Rust. It is difficult but not impossible. Part of my learning was to unlearn what I have learned over the years. I also think that part of learning Rust was to know what it can do as of now and what it can do potentially in the future. One might not want to learn Rust because it can not do XYZ, but it might be able to soon. Needs based.

My learning is based on doing, give me an end goal then start to work towards that end goal. As I walk through those steps, I am learning without knowing that I'm learning. Show me outcomes as I get there. I used a book that I use to learn programming concepts, The Ray Tracer Challenge by Jamis Buck. Here is my outcome from that book rustic-ray. The book is great because the language is pseudo code. My point is that the book walks through progressively more difficult coding paradigms leaving the implementation up to the reader and the language they use. Challenging me to learn how to implement and learn aspects of Rust using a real-world program. How to use traits, how to struct data, if doing bidirectional cyclic data struct is challenging how else can you solve the problem. Move beyond the book and try multithreading. Try to implement cyclic bidirectional data structure and would RC<T> help. How would you add a GUI to the app, my current challenge?

I enjoy progressive learning and when I get to things like traits, lifetimes, multithreading I have already learned the foundational things like struct, implementation, that learning the more difficult items are not convoluted with learning the more mundane things. Not only do I learn the language paradigms I also learn the syntax, cannot forget that learning includes syntax and file structure. I think repetition is good as well.

I think with Rust there is a lot that can go wrong because of the nature of being safe. Ironically and it might be counter intuitive to teach by correcting a lot of mistakes. They say we learn a lot by our mistakes. Teach by correcting code that does not compile. Teach by showing ways to fight the borrow checker and win! Teach how something does not work because of lifetimes and then correct it. Do not start with a project that works start with one that does not.

Teach the tools that come with Rust that might be more difficult in other languages or not built in. Teach how to document code, format code (fmt) and write code idiomatic using clippy. Once I learned documenting, I was blown away how easy it was, the ability to put example code that runs, and documentation that has a well formatted outcome at almost no cost to me. Next, I'm learning crates.io and publishing a library. Teach the whole rust ecosystem.

Rust by no means is missing this, just can be better and more. To compare learning Rust with other languages in particular Go, “The Book” was the selling point. Which works only if you learn by reading. Which for me is okay, because back when I started programming all I had where books, the bookstore, and a library, it was easy. But how can The Book be put into different mediums if reading is not the way? "The Video"?!?! The Rustlings was a good start as well, but my suggestion is to have that online. Trying to build something I don't know to teach me the thing I don't know was a challenge and a bit counterintuitive.

  • Teach by unlearning what one already knows. You won't get the same thing here as you do elsewhere.
  • Teach by using multiple mediums of the same topic, reading, writing, and watching. It is a challenge to read something but not have a video of the same thing or a sandbox to write the same code. The documents do well with running the examples.
  • Teach progressively baby steps, crawl, walk, run, drive a car! Going from safe ----> unsafe! Going from easy ----> challenging!
5 Likes
6

I'm also interested in this, although I don't know if I have much time and energy available to contribute to it. My day job is tutoring people in programming online, and I've tutored a few people in Rust (although it's hard to compare with other languages, because my Rust clients are usually experienced programmers who are just new to Rust, while my other clients are usually less experienced).

7

This seems like a good idea, although I'm skeptical of the value of a survey distributed through internals/reddit/etc as there would be quite a bit of survivorship bias...

Many of the rust meetup groups have sessions where people can hack on their rust projects and get help from other people who are around. It might be a good idea to talk to the people who run or attend those, especially people going for the first time.

It would also be good to specify what skill range is being focused on: it sounds like it would primarily be focused on beginner to intermediate level?

3 Likes
8

This is a really good point -- it'd be good to decide were to focus first, I imagine. Another relevant factor might be people's backgrounds. As @elidupree noted:

I feel like this will be quite relevant.

1 Like
9

I think it's a good idea and I'm interested in participating. I have no qualifications other than I wrote Common Rust Lifetime Misconceptions which many people have told me was the article that finally made lifetimes click for them. I also occasionally answer Rust questions on StackOverflow, the learnrust subreddit, and on URLO.

Who will be the target audience of this survey? I expect the answer is probably "beginners who are currently learning Rust" but I would like to suggest an alternative audience. I think the quality of information, both in its detail and how actionable it would be, would be significantly higher if we surveyed frontline educators (e.g. regulars in the StackOverflow Rust chat, learnrust subreddit, rust subreddit, URLO, official Rust discord server, community Rust discord, Rust Mentors, Rust tutors, etc) about their experiences in helping Rust beginners rather than surveying Rust beginners directly. The main problem I see with surveying Rust beginners directly is because they don't understand Rust they also can't articulate why they don't understand what they don't understand, whereas Rust educators would be able to provide this information on behalf of the Rust beginners they have helped. Also, the survey should only contain open-ended questions, no multiple-choice.

I also think literally anything other than a survey would be more helpful. It's rare to find videos of people genuinely learning Rust for the very first time but examples like this exist and I think they're much more valuable and insightful than putting a bunch of multiple-choice survey answers into a graph and then drawing often dubious and erroneous conclusions from the obviously very low quality data.

3 Likes
10

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.

2 Likes
11

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
12

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.

2 Likes
13

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

14

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.

4 Likes
15

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

16

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:

5 Likes
17

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.

3 Likes
19

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
20

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
22

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 ?