I've been thinking about the learning curve for Rust lately, and why it feels so hard to learn. I think the reason is because the complexity is all front-loaded, and the resources generally don't actively reduce that front-loading¹.

There are two well-trod paths for learning Rust: read long books, or learn by example.

These work for some people, but they have harsh learning curves. The books are quite long and generally you have to get through all of it before you can do things that are generally useful². On the other hand, learning by example generally works only if you're already quite familiar with low-level programming and just need to learn the syntax and other little Rust-y bits.

This keeps a lot of people out of Rust by sheer lack of time, if nothing else. If it takes a month of evenings to work through a Rust book, are you going to learn Rust or are you going to pick up Go, where you can spend a couple of evenings then write something useful? I know which one I'd pick, because I picked Go at work to avoid that learning curve for my coworkers.

Most other languages have much shorter time before you can feel productive and knowledgable. That feeling is critical in learning a language and bringing newcomers into the fold. With Go or Python or TypeScript, an experienced developer can be writing useful code in a day or two. Among the languages I've used at work, Elixir was probably the longest learning curve, and it topped out at three days to writing production code. Even C and C++ have shorter learning curves than Rust, although that's a bad thing, because now we get a lot of people who are confidently writing bad C and C++, just yeeting buffer overflows into production.

I think the best way to reduce this learning curve is to recognize two things:

1. Other languages have the problems Rust prevents, but just let you confidently ignore them. (I'm looking at you, all the data races I've written in Go and buffer overruns I've written in C++.)
2. You can write useful Rust with a lot less deep understanding if you pair with someone else.

This isn't an original thought. Julia Evans said that "having someone elide away the harder stuff so I can focus on what’s easy feels to me like a good way to learn," and I couldn't agree more. I think this might be one of the ideal ways to learn Rust.

One of the best ways to reduce the learning curve is to bootstrap up to writing small programs with a little bit of help, and then pair to get to proficiency. You can bootstrap from something like Rust by Example or Rustlings to get the syntax under your fingers and get some knowledge of the language. Then you can get started on a real project and get help when you get stuck.

I think this is particularly effective in a workplace environment. These problems that Rust front-loads are still important in other languages, but they're handled at code review time (if you're lucky). With Rust, we can do the same thing, and write code that mostly would work (maybe take some shortcuts with clones and reference counts), and then use pairing and code review to tighten it up!

I'm investing in this idea some more. Right now I'm working on two things:

1. Introducing Rust at work, with a prototyping phase to make sure that it'll work for our team and our problems.
2. Writing a Rust training course (with the table of contents shamelessly lifted from Comprehensive Rust, then modified) focused on getting people just to the point of pairing with a more experienced Rust programmer³.

If anyone has any other ideas for reducing Rust's learning curve, let me know!