Creating an Easy Mode for Rust

image

Rust has a reputation for being difficult to learn. This perception directly conflicts with one of the community aims: empowerment. Doubt breeds fear. And fear makes it harder for people to justify learning a new skill.

Rust provides the world with an opportunity to write software that’s resource efficient and resistant to security concerns. Any time that someone is put off from attempting to learn the language because they perceive it to be too hard—or that they’re inadequate—is a failure.

The Rust community is attempting to address this. The Lang Team’s roadmap for Rust 2024 is explicitly designed to make the language and its ecosystem “more ergonomic”.

This post is my attempt to provide some places where people learning Rust encounter issues. The original intention was to find a few things that could be addressed within the language itself. Unfortunately, most of the papercuts that I’ve found are outside of the core language.

Some guiding principles:

  • every decision point (“do I use cargo or rustup?”, “should I use HashMap or BTreeMap?”) is a place for confusion
  • the impression of prospective users matters more than people who are already invested

Improving First Impressions

We must place beginners first. Being welcoming to new users is essential to Rust’s overarching goal of empowerment. We don’t need growth for growth’s sake, but we don’t want people walking away from Rust because they’re discouraged.

Too many places to look

For a casual observer, there are too many places to look for resources with official or quasi-official status.

Some observations and recommendations:

Too many commands

At some point, many heavily used commands should be consolidated under a single command-line tool called rust. This would become cargo, rustc, and rustup as well as fold in clippy and rustfmt.

Too much friction for tiny projects

My hunch is that people start with a new language by starting small. Rust should be fun for programming small utilities.

Let’s make it trivial to get started. Because so much Rust depends on third-party crates, it’s hard to create a Rust program that fits in a single file. I would love to see something like cargo-script become a first-class part of the ecosystem.

Let’s also provide a first-class interactive option. Many people attracted to Rust come from dynamic languages, where a build step isn’t necessary. The evcxr (Evaluation Context for Rust) project should probably be folded into the the overall Rust.

It should be easy to spin up a local playground. The playground provides a very useful service: it enables people to experiment without needing to invest a lot of effort.

Helping People to Build a Mental Model of Rust

Learning Rust well involves learning to navigate a social landscape that is rich in jargon and implicit cultural norms.

What is the difference between String and &str?

If the Rust community finds a way to quickly answer this question–which happens to be the most-highly rated question on Stack Overflow for the #rustlang tag– to people who are new to Rust, then it will succeed as a general purpose programming language. Without a concise answer, Rust will remain mysterious to many.

Understanding String vs &str implies an understanding of the ownership system, which implies an understanding of the lifetime system. That probably means that you’ve been exposed to pointers, references and perhaps even aliasing. There’s usually a discussion about mutability intertwined here. Gaining an intuition of data types that represent text benefits from understanding encodings, which benefit from understanding how CPUs operate.

I’ve yet to find a way through this for complete beginners. Learners with that already know another systems programming language have a distinct advantage here.

The common strategy is to tell users that they should “Just use String for now”. Everyone knows that this is only a half-answer. An answer designed to give learners some time. But it’s not even a half-answer. It won’t take long before they encounter an function’s parameter that takes &str (or worse AsRef<str>) as an argument.

Hard to find defaults

Every time that you place a decision point in front of your users, you introduce cognitive load. Cognitive load is particularly expensive for beginners, who need to retain lots of details in working memory to make progress while writing.

The Rust community values precision. We care about how our values are laid out in memory. We want to give developers strong type safety so that they can write robust programs.

Unfortunately for new users of Rust, there are often multiple choices for things that seem like there should be none.

  • Which numeric type is “right”?
  • When should I use &str, String, Cow, T: Display, T: AsRef<str>, T: Into<string> or any of the other options?
  • HashMap vs BTreeMap for mapping keys to values
  • It’s difficult to understand what the difference is between a few similar-sounding traits, e.g. ToString vs ToOwned vs Into<string> and Debug vs Display.
  • Why are there so many ways to convert types? When should I use the as keyword? What about .into(), T::from(), and .try_into().

We should get better at giving guidance.

Difficult to know which crate to use

Rust has a rich crate ecosystem backed by crates.io, which provides semantic versioning and immutable versions. This allows for rapid and robust innovation by library authors, backed with dependability. This ecosystem also has its downsides.

The no namespaces policy of crates.io is vulnerable to name squatting and individual crates, that often written by a single author, are vulnerable to side-channel attacks.

I think that there may be a space for a another crate registry that provides curated crate collections, probably within reserved namespaces. (If I had a few million dollars, that would be my startup idea!)

This situation is difficult to navigate, especially for beginners. Our crates have cute names rather than descriptive names. It takes some experience to know that parking_lot is the crate for excellent synchronization primitives.

Perhaps one of the ways to address this is to provide curated crate collections.

Everyone’s most loved programming language

Learning Rust feels hard for many people. More significantly, people put off learning Rust because of a perception that it might be too hard.

It’s often argued that Rust’s ownership and lifetimes concepts are novel and therefore difficult. I wonder whether this is entirely true. All programming languages have difficult concepts. My suspicion is that the difficulty in learning Rust is partially caused by factors that sit outside of the core language. What do you think?

You’re welcome to contact me by email or on Twitter. This post is also being discussed on r/rust.

14 notes

  1. bigntallmike reblogged this from tim-mcnamara and added:
    #rust #programming #code
  2. jukain4216 reblogged this from tim-mcnamara
  3. daemonhxckergrrl reblogged this from tim-mcnamara
  4. tim-mcnamara posted this