extern crate vs use in Rust: How Not to Confuse Them and Write Correctly

extern crate and use in Rust: What's the Catch and How to Avoid Pitfalls

If you've ever written even a couple of lines in Rust, you've certainly encountered the extern crate and use constructs. At first glance, they seem to do the same thing — bring in external code. But the devil, as always, is in the details. This question is among the most popular on Stack Overflow (thousands of views!), and beginners constantly get confused by it. Let's finally figure out once and for all how extern crate differs from use, where the magic happens, and how to avoid typical mistakes.

The Short Version: What's What

Imagine your Rust project is a big house. extern crate is the delivery of building materials to the site. You tell the compiler: "Hey, I want to use this box of bricks (crate), bring it over." Without this command, the compiler won't even know an external library exists.

use is the internal navigation inside the house. You say: "I want the door from this room (module) to lead directly to the kitchen (a specific type or function)." use creates aliases (short paths) to already known modules and types, so you don't have to write the full path every time.

Simply put: extern crate answers the question "what can we even use?", while use answers "how can we conveniently refer to it?".

Historical Context: Why Everyone Gets Confused

The confusion didn't come out of nowhere. In older versions of Rust (before the 2018 edition), extern crate was mandatory for any external crate. It looked like this:

// Rust 2015 — old style\nextern crate serde;\nuse serde::{Serialize, Deserialize};

Starting with Rust 2018 edition, the compiler learned to find dependencies from Cargo.toml on its own. Now, writing extern crate for most crates is not necessary. It's enough to just add the dependency to Cargo.toml and immediately use use:

// Rust 2018+ — new style (extern crate is not mandatory)\nuse serde::{Serialize, Deserialize};

This is where the nightmare for beginners begins. They see old examples where extern crate is used, new ones where it isn't, and try to figure out when it's actually needed. Spoiler: it is needed, but in very rare cases.

When extern crate Is Still Needed (And This Is Important!)

There are three situations where you can't do without extern crate:

\n
• Linking to system libraries via #[link] — if you're writing bindings to C/C++ code and using the #[link(name = "sqlite3")] attribute, then extern crate is mandatory.
\n
• Global macros — some crates (e.g., log) export macros that need to be visible throughout the entire program. In Rust 2018, you need to write extern crate log; for this.
\n
• Building with non-standard crate names — if you use extern crate my_crate as foo; to rename a crate.
\n

In all other cases, extern crate is a relic of the past. But many developers continue to write it out of habit, and beginners copy code from old tutorials.

Top 5 Mistakes When Working with extern crate and use

Mistake #1: Using extern crate where it's not needed

The most common problem. You add a crate to Cargo.toml, then write extern crate rand; — and the code works. But it's an extra line. In modern projects (Rust 2018+), it only clutters the code and can confuse other developers.

// Bad (redundant in Rust 20