Why Rust's learning curve seems harsh, and ideas to reduce it
Monday, January 16, 2023
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-loading1.
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 useful2. 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:
- 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++.)
- 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:
- Introducing Rust at work, with a prototyping phase to make sure that it'll work for our team and our problems.
- 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 programmer3.
If anyone has any other ideas for reducing Rust's learning curve, let me know!
For example, early Rust programmers probably shouldn't be dealing with tons of borrows and tricky lifetimes. Those are an optimization! You can get away with clones and reference counts for a long time and then dive into the more advanced things when you need them or when you're ready for them.
If you are, I'm sorry. Know that things can get better. C++ abused me, but I left and turned my life around. You can get help, too.
It will be open-source! If you're interested in helping test the material, please reach out to me. My email's in the footer, or Zulip's good if you're a Recurser.
If this post was enjoyable or useful for you, please share it! If you have comments, questions, or feedback, you can email my personal email. To get new posts and support my work, subscribe to the newsletter. There is also an RSS feed.
Want to become a better programmer? Join the Recurse Center!