How to Debug Rust in VS Code with rust-analyzer

More than half of respondents in Rust's 2026 debugging survey said they do not currently use a debugger, while poor value representation was the most common debugging complaint. The Rust team published those findings on September 7, 2026, after collecting more than 2,300 responses. If you have been relying on print statements because setting up a Rust debugger feels harder than the bug itself, this tutorial shows a practical VS Code workflow using rust-analyzer and the platform's supported debugging extension. 

Why Rust debugging still feels awkward

The survey found that more than 81% of respondents avoided debuggers in some situations because logs or print debugging felt easier or faster. Among people who did use debuggers, stepping through code was the dominant use case, while only about a quarter reported using a debugger for asynchronous code. More than half of respondents who stepped through Rust code said they had encountered problems, with asynchronous code and macros among the most common trouble spots. That explains why a debugger can be useful without being the only debugging tool you use. 

What you need before starting

You need a working Rust installation, Visual Studio Code, and the rust-analyzer extension. Rust's VS Code documentation currently recommends rust-analyzer and identifies the older Rust extension as deprecated. You also need a debugger extension: Microsoft's C++ extension is supported on Windows, while CodeLLDB is supported on macOS and Linux. The exact debugger backend therefore depends on your operating system. 

1. Install Rust with rustup if it is not already installed.
2. Open VS Code and install the rust-analyzer extension.
3. On Windows, install the Microsoft C++ extension for debugging.
4. On macOS or Linux, install CodeLLDB.
5. Open a new terminal and run rustc --version to confirm that the compiler is available.

If rustc --version works, the Rust compiler is visible to your terminal. You can also run rustup update to update the installed Rust toolchains. Rust's stable releases arrive on a regular six-week cadence, so keeping the toolchain current is useful when working with editor tooling. 

Create a small Rust program to debug

A small reproducible program makes debugger setup much easier to verify than starting with a large application. Create a project with Cargo, Rust's package manager and build tool, by running cargo new debug-demo. Move into the project with cd debug-demo and open it in VS Code with code .. Cargo creates the project manifest and a src/main.rs file for the executable. 

cargo new debug-demo
cd debug-demo
code .

Replace the contents of src/main.rs with a program that gives you something meaningful to inspect.

fn calculate_total(price: i32, quantity: i32) -> i32 {
    price * quantity
}

fn main() {
    let price = 25;
    let quantity = 4;
    let total = calculate_total(price, quantity);

    println!("Total: {total}");
}

Run cargo run once before opening the debugger. You should see Total: 100 in the terminal. This confirms that Cargo can compile the project and that the program starts normally before you introduce debugger-specific steps. 

Set your first breakpoint

A breakpoint tells the debugger to pause execution at a particular line. In VS Code, open src/main.rs and click in the gutter to the left of the println! statement. You should see a breakpoint marker appear on that line. Current VS Code guidance for Rust also notes that the Debug: Allow Breakpoints Everywhere setting may need to be enabled before using breakpoints in this workflow.

Next, open the Command Palette and run Rust Analyzer: Debug. You can also use the Debug CodeLens associated with main() when it appears in the editor. The debugger should start the program and stop before the selected line executes. At that point, the important difference from print debugging becomes visible: execution has paused while the program's current state remains available for inspection. 

Inspect variables before they change

With execution paused, inspect price, quantity, and total in the debugger interface. This is particularly useful when a calculation looks wrong because you can determine whether the input was already incorrect or whether the error happened during the calculation. Use the debugger's step controls to move through the function instead of repeatedly adding temporary print statements. Rust's VS Code integration is designed to provide basic debugging directly through rust-analyzer. 

For example, place the breakpoint on the line that calculates total and start debugging again. At that point, price should contain 25 and quantity should contain 4. Step forward and inspect total; it should become 100. If one of those values is unexpected in a real application, you have narrowed the problem to the code that produced that value rather than guessing where the failure occurred.

Use print debugging when it is actually faster

A debugger is not automatically better than logging. Rust's own survey found that more than 81% of respondents sometimes preferred logs or print debugging because they were easier or faster, and Rust developers commonly use the dbg! macro alongside ordinary print debugging. For a simple value, dbg! can be the quickest way to see what a function is receiving or returning.

fn calculate_total(price: i32, quantity: i32) -> i32 {
    dbg!(price);
    dbg!(quantity);
    price * quantity
}

The useful approach is to treat the two methods as complementary. Use dbg! or logging when you need a quick observation across repeated executions, and switch to a debugger when you need to stop at a precise point and inspect several values or the call stack. This matters even more in larger programs where adding and removing temporary output can become its own source of noise.

Test the failing path instead of guessing

When the bug is associated with a specific behavior, a test can give you a repeatable starting point for debugging. Rust tests are functions marked with the #[test] attribute, and Cargo runs them with cargo test. Cargo can also filter tests by name, which is useful when a project contains many tests.

#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    fn calculates_total() {
        assert_eq!(calculate_total(25, 4), 100);
    }
}

Run cargo test after adding the test. If it fails, you now have a reproducible case instead of an error that only appears during a larger application run. You can then reproduce the relevant behavior under the debugger and inspect the values at the point where they diverge from what the test expects. That combination is usually more useful than repeatedly running the entire application and watching its output. 

Where Rust debugging still has limits

The September 2026 survey shows why you should not expect the debugger to solve every Rust debugging problem. More than 74% of respondents reported poor representation of values as a debugger pain point, while more than 55% reported problems printing variables. Just over half reported problems while stepping through code, and asynchronous code was the most frequently reported situation among those users. 

Rust's team has identified better representations for enums, collections, and string types as areas worth improving, along with better asynchronous debugging and stepping through state machines such as iterators and futures. Library authors should also know about the debugger_visualizer attribute, which can embed debugger visualization information into debug data; the survey found that nearly 62% of respondents who identified as library authors were not aware of it. These findings are a useful warning against treating a debugger as a complete replacement for logging, tests, or careful code inspection. 

How to tell that your setup is working

A working setup should let you create a Cargo project, build it without errors, place a breakpoint in main.rs, start a Rust Analyzer debug session, and stop execution at that breakpoint. You should then be able to inspect local variables and continue execution until the program finishes. If the debugger does not start, first confirm that rust-analyzer is installed and that the appropriate platform debugger extension is present. VS Code's current Rust documentation specifically lists Microsoft C++ for Windows and CodeLLDB for macOS and Linux. 

If rust-analyzer itself appears to be malfunctioning, check its installed version and inspect the Output panel under Rust Analyzer Language Server. The rust-analyzer troubleshooting guide recommends checking the server version first and using its logging options when the normal diagnostics are not enough. That gives you a cleaner troubleshooting path than repeatedly reinstalling extensions without knowing which component is failing. 

What to use for your next Rust bug

Start with the smallest tool that can answer the question. Use a test when you need a failure you can reproduce, dbg! or logging when you need quick observations across executions, and the VS Code debugger when you need to stop execution and inspect the program's state. The Rust team's latest survey makes clear that many developers still find print debugging faster, so there is no reason to abandon it. The practical goal is not to debug everything with one tool; it is to make each failure easier to see, reproduce, and fix.