A Potential Rust Learning Project Group

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?

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?

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:

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

I feel like this will be quite relevant.

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

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.

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

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/ 5

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

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:

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.

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

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.

although it's hard to compare with other languages

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.

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?

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.

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.

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 10 with the aim of collaborating on survey design. I look forward to working with you all on this.

The project sounds great

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

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.

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.

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.