New to Rust? Don’t make these common mistakes

When you start learning a programming language, you will inevitably experience some frustration along with the fun. Some of that frustration comes with learning anything new and complicated, and some is unnecessary—self-inflicted, even! When learning Rust, it helps to know about basic things you should do, as well as things you really shouldn’t.

This article is a brief look at four “don’ts”—or “don’t do this, do that instead.” It’s advice worth taking to heart when learning Rust.

Don’t assume Rust learning material is up to date

Rust is a fast-moving language, and the documentation doesn’t always keep up. Don’t be misled by guides or other learning materials that contain outdated examples. Anyone can fall into this trap, but it’s twice as easy if you are unfamiliar with the language’s evolution or its current state of the art.

For instance, older editions of Rust had a macro named try!, which was used for unwrapping a result and propagating any errors that might be returned. It’s since been superseded by the? operator, which is a native piece of Rust syntax and not a macro. But if you rely on older documentation, you might run into examples featuring try! or other outdated concepts as if they were current.

Any Rust documentation older than two years might already be getting bewhiskered, so check the dates. Double your skepticism when you come across undated material, with the possible exception of the official Rust documentation pages.

Don’t revert to using C/C++ (or any other language) in Rust

Some Rust concepts may be frustrating to learn at first. The ownership/borrowing metaphors for memory management and type-based error handling both impose a significant learning curve. But don’t fall into the trap of trying to work around these concepts by resurrecting metaphors from other languages.

In particular, don’t try to use C-style, or even C++-style, memory management or raw memory access by way of pointers. References are safe because they are always tracked through borrowing and ownership. But pointers—which you must explicitly opt-in to use—can in theory point to anything, so they’re inherently unsafe.

The solution here isn’t to liberally sprinkle your code with unsafe{} so you can dereference pointers inside those regions. It’s to use references and not pointers from the get-go. Get to know types like Box, Rc, and Arc, which allow using ownership rules for arbitrary regions of memory. That way, you’ll never have to do the raw pointer dance in the first place.

If you have literally no choice in the matter, confine pointers to the smallest possible unsafe{} regions and get safe Rust values out of them instead.

Your best bet is to learn the native Rust way to do things and avoid falling back on habits from other languages. C++ developers often get hung up on trying to reproduce C++’s idioms (and quirks, and even its limits) in Rust. If you are one of those beleaguered folks, the C++ to Rust Phrasebook might come in handy. It shows you how to transition elegantly from C++ to Rust concepts.

Don’t try to learn all the Rust string types (yet)

Rust’s ecosystem has many types of strings for processing text, many of which are for highly specific tasks. Unless you’re trying to do something more than just passing strings between functions or printing them to the console, you don’t need to worry about them.

Focus on the two most common string types: str (immutable, essentially what string literals give you in code), and String (mutable, always stored on the heap). Use str to create string constants, and use &str to get borrowed references to existing string values. Everything else can wait, for now.

Don’t sweat using.clone() to sidestep borrowing (at first)

When you’re writing your first Rust programs, the complexities of ownership and borrowing can be dizzying. If all you want to do is write a simple program that doesn’t need to be performant or hugely memory-optimized, Rust’s memory management might seem intrusive.

This isn’t always going to be true; in fact, your growth as a Rust developer depends on learning when memory management is essential. But in the very early stages of Rust-dom, when you’re still getting your sea legs inside the language’s syntax and tooling, that feature can feel like a burden.

One way to reduce your worry about borrowing—both now and later—is to clone objects rather than transfer ownership. Cloning creates a new instance of the same data but with a new, independent owner. The original instance keeps the original owner, so there are no issues with object ownership. And, as with the original object, the clone will be dropped automatically once it goes out of scope.

On the downside, constructing a clone can be expensive, especially if you’re doing it many times in a loop. You’ll want to avoid it in performance-sensitive code. But until you’re writing such code—and learning how to use metrics to detect hot paths in the code—you can use cloning to clarify the ownership chain of your objects.