CorrcodeModify

2025-05-29 08:00:00

Few developers have been as influential to my career as Niko Matsakis. Of course he is a world-class engineer with a PhD from ETH Zürich, a Rust core maintainer who has been working on the language for way more than a decade, and a Senior Principal Engineer at AWS. But more importantly, he is an empathetic human and an exceptional communicator.

I’ve personally been waiting for one year to get him on the show and steal one hour of his precious time. Now, finally, I got my chance at live recording at Rust Week 2025. The result is everything I hoped for: a trip down memory lane which takes us back to the early days of Rust, an honest and personal look at Rust’s strengths and weaknesses, and a glimpse into the future of the language. All of that packed with insightful anecdotes based on Niko’s decades of experience. If you like Rust, you will enjoy this episode.

Show Notes

About Rust

Rust is the language which brought us all together. What started as a side-project of Graydon Hoare, a single developer at Mozilla, has grown into a worldwide community of hobbyists, professionals, and companies which all share the same goal: to build better, safer software paired with great ergonomics and performance.

About Niko Matsakis

Niko is a long-time Rust core team member, having joined the project in 2012. He was and still is part of the team which designed and implemented Rust’s borrow checker, which is the language’s most important feature. He has been a voice of reason and a guiding light for many of us, including myself. His insightful talks and blog posts have helped countless developers to see the language and its goals in a new light.

Special Thanks

Thanks to RustNL, the organizers of Rust Week 2025 for inviting Simon and me to record this episode live. They did a fantastic job organizing the event, and it was an honor to be part of it.

Links From The Episode

• RustWeek 2025 - Rust conference in Utrecht where we recorded this live episode
• DataPower - Niko’s employer before working on Rust
• XSLT - Language to transform arbitrarily shaped XML into different arbitrary shapes
• ETH Zürich - Niko’s Alma Mater
• Mozilla - Niko’s first employer while working on Rust
• rustboot - Rust’s first compiler written in OCaml
• Don Quixote - Personification of impractical idealism, just like Rust was in the beginning
• Steve Klabnik’s FOSDEM talk - Coining “The Graydon years”, Slides, Recording of the same talk for ACM
• Rust 0.2 Keywords - ret for return, cont for continue
• Boxes in Rust 0.8 - ~T and @T as syntax features instead of Box<T> and Rc<T>
• Green Threads - Like OS threads, but greener!
• std::threads - Not green, just part of the standard library
• std::rc::Rc - The @T of std
• std::boxed::Box - The ~T of std with some special compiler sauce
• std::sync::Arc - Thread safe Rc
• pyo3::Py - A pointer type in a different library!
• The Rust Book: Understanding Ownership - Ownership and borrowing are the first third of “the simple core of Rust”
• The Rust Book: Using Trait Objects - Trait-based dispatch being the second part of “the simple core of Rust”
• std::marker::Send - A trait without even a method to dispatch, aptly placed in the marker module
• std::marker::Sync - Another example of a marker trait
• Linear Type Systems - Foundational research topic for borrowing in Rust
• regex - “Real stuff” built in Rust
• rayon - Turning iterators into parallel processing
• Tokio Async Runtime - An entire async ecosystem as a perfomant library
• Comment on RFC 2394 - The beginning of the await x / x.await discussion?
• Alex Crichton - Rust compiler, wasm, and lang-advisors team member
• cramertj - Rust lang-advisors and libs-contributors team member
• withoutboats - Rust team alumni
• Carl Lerche - tokio maintainer
• aturon - Rust team alumni
• ALGOL 60 - Doesn’t look like C
• try blocks - Do we need a postfix match operator for this?
• Rust Blog: Announcing Rust 1.31 and Rust 2018 - A watershed moment for Rust
• Non-lexical lifetimes - Included in 1.31 and Rust 2018
• Santiago Pastorino - Rust compiler contributor, worked on non-lexical lifetimes
• Makefile Example - “We don’t need cargo, Make is fine”
• Rust Blog: Laying the foundation for Rust’s future - Mozilla’s parting gift to Rust?
• Tyler Mandry - Rust lang team co-lead with Niko
• Josh Triplett - Rust lang, cargo, and libs team member
• Amazon S3 Express One Zone storage class - Super low latency S3, written in Rust
• Amazon Aurora DSQL - Serverless SQL, an AWS project that started 100% in JVM and finished 100% Rust
• Just make it scale: An Aurora DSQL story - Blog post detailing the Aurora DSQL Rust rewrite
• Rust in 2025: Targeting foundational software - Niko’s vision for Rust
• Be excellent to each other - Party on dudes!

Official Links

• Rust Language
• Rust Foundation
• Niko Matsakis’ Homepage
• Niko Matsakis on GitHub

2025-05-21 08:00:00

The Rust standard library, affectionately called std, is exceptionally well-designed, but that doesn’t mean it’s perfect. More experienced Rust developers tend to navigate around some of its sharper parts.

In this article, I want to highlight the areas in std that I personally avoid. Keep in mind that this list is subjective, so take it with a grain of salt. My intention is to point out some pitfalls and suggest alternatives where appropriate.

Threading

Rust’s threading library is quite solid. That said, managing threads can be a bit of a footgun. In particular, forgetting to join a thread can have some unexpected side effects.

use std::thread;
use std::time::Duration;

struct Resource;

impl Drop for Resource {
    fn drop(&mut self) {
        // This never gets called
        println!("CRITICAL CLEANUP: Resource dropped");
    }
}

fn main() {
    let handle = thread::spawn(|| {
        let resource = Resource;
        // Do some work... 
        thread::sleep(Duration::from_secs(60));
        // Resource should be dropped here when thread ends
    });
    
    // Main thread exits immediately.
    // But! We forgot to join the spawned thread!
    // handle.join().unwrap();
}

In the above scenario, cleanup tasks (such as flushing caches or closing files) might not get executed. So, even if you do nothing with the handle, it is still a best practice to join() it. For more details on the topic, check out matklad’s article: “Join Your Threads”.

In fact, there was a proposal to make std::thread::JoinHandle be #[must_use], but it was ultimately declined because it would produce too many warnings.

This comment summarized the situation pretty well:

I’d say the key issue here is that thread::spawn is the easiest way of spawning threads, but not the best one for casual use. Manually calling .join().unwrap() is a chore and easy to forget, which makes thread::spawn a potential footgun.

For new code, I recommend using thread::scope instead, which is a much better API in every conceivable way. The documentation addresses the above issue directly:

Unlike non-scoped threads, scoped threads can borrow non-'static data, as the scope guarantees all threads will be joined at the end of the scope. All threads spawned within the scope that haven’t been manually joined will be automatically joined before this function returns.

Alternatively, you could use a thread pool library or rayon, in case you have an iterator you want to parallelize without manually managing threads.

std::collections::LinkedList

Implementing a linked list in Rust is not easy. That’s because Rust’s ownership model is detrimental to self-referential data structures.

Some people might not know that the standard library ships an implementation of a linked list at std::collections::LinkedList. In all those years, I never felt the urge to use it. It might even be the least-used collection type in the standard library overall.

For all ordinary use cases, a Vec is superior and straightforward to use. Vectors also have better cache locality and performance characteristics: all items are stored in contiguous memory, which is much better for fast memory access. On the other side, elements in a linked list can be scattered all over the heap. If you want to learn more, you can read this paper, which contains some benchmarks.

You might be wondering why linked lists get used at all. They have their place as a very specialized data structure that is only really helpful in some resource-constrained or low-level environments like a kernel. The Linux kernel, for example, uses a lot of linked lists. The reason is that the kernel’s intrusive linked list implementation embeds list nodes directly within data structures which is very memory efficient and allows objects to be in multiple lists simultaneously without additional allocations. ¹

As for normal, everyday code, just use a Vec. Even the documentation of LinkedList itself agrees:

NOTE: It is almost always better to use Vec or VecDeque because array-based containers are generally faster, more memory efficient, and make better use of CPU cache.

I believe the LinkedList should not have been included in the standard library in the first place. Even its original author agrees.

There are some surprising gaps in the API; for instance, LinkedList::remove is still a nightly-only feature²:

use std::collections::LinkedList;

fn main() {
    let mut list = LinkedList::from([1,2,3]);
    dbg!(list);
    
    // This is still unstable!
    // https://github.com/rust-lang/rust/issues/69210
    // The operation should compute in O(n) time.
    // Panics if out of range...
    // list.remove(0);
}

Even if you wanted a linked list, it probably would not be std::collections::LinkedList:

• It doesn’t support O(1) splice, O(1) node erasure, or O(1) node insertion - only O(1) operations at the list ends
• It has all the disadvantages of a doubly-linked list but none of its advantages
• Custom implementations are often needed anyway. For example, many real-world use cases require an intrusive linked list implementation, not provided by std. An intrusive list is what the Linux kernel provides and even Rust for Linux has its own implementation of an intrusive list.
• Arena-based linked lists are often needed for better performance.

There is a longer discussion in the Rust forum.

Better implementations exist that provide more of the missing operations expected from a proper linked list implementation:

• contain-rs/linked-list
• intrusive-collections

There’s a thing to be said about BTreeMap as well, but I leave it at that. ³

Path Handling

Path does a decent job of abstracting away the underlying file system. One thing I always disliked was that Path::join returns a PathBuf instead of a Result<PathBuf, Error>. I mentioned in my ‘Pitfalls of Safe Rust’ article that Path::join joining a relative path with an absolute path results in the absolute path being returned.

use std::path::Path;

fn main() {
    let relative_path = Path::new("relative/path");
    let absolute_path = Path::new("/absolute/path");

    // This will return "/absolute/path"
    let result = relative_path.join(absolute_path);
    assert_eq!(result, absolute_path); 
}

I think that’s pretty counterintuitive and a potential source of bugs. On top of that, many programs assume paths are UTF-8 encoded and frequently convert them to str. That’s always a fun dance:

use std::path::Path;

fn main() {
   let path = Path::new("/path/to/file.txt");
   
   // The awkward dance with multiple conversions
   match path.as_os_str().to_str() {
       Some(s) => {
           // Yay! We can use string operations
       },
       None => {
           // Oh well, it's not UTF-8.
           // Many developers just use lossy conversion to avoid dealing with this
           // Which might _silently_ corrupt path data but keeps the code moving...
           let lossy = path.to_string_lossy();
           
       }
   }
}

These path.as_os_str().to_str() operations must be repeated everywhere. It makes path manipulation every so slightly annoying.

There are a few more issues with paths in Rust:

• Path/OsStr lacks common string manipulation methods (like find(), replace(), etc.), which makes many common operations on paths quite tedious
• The design creates a poor experience for Windows users, with inefficient Path/OsStr handling that doesn’t fit the platform well. It’s a cross-platform compromise, but it creates some real problems.

Of course, for everyday use, Path is perfectly okay, but if path handling is a core part of your application, you might want to consider using an external crate instead. camino is a good alternative crate, which just assumes that paths are UTF-8 (which, in 2025, is a fair assumption). This way, operations have much better ergonomics.

Platform-Specific Date and Time Handling

In my opinion, it’s actually great to have some basic time functionality right in the standard library. However, just be aware that std::time::SystemTime is platform dependent, which causes some headaches. Same for Instant, which is a wrapper around the most precise time source on each OS.

Since time is such a thin wrapper around whatever the operating system provides, you can run into some nasty behavior. For example, this does not always result in “1 nanosecond” on Windows:

use std::time::{Duration, SystemTime};

fn main() {
let now = SystemTime::now();
dbg!((now + Duration::from_nanos(1)).duration_since(now));
}

The documentation does not specify the clock’s accuracy or how it handles leap seconds, except to note that SystemTime does not account for them.

If you depend on proper control over time, such as managing leap seconds or cross-platform support, you’re better off using an external crate. For a great overview, see this survey in the Rust forum, titled: ‘The state of time in Rust: leaps and bounds’.

In general, I believe std::time works well in combination with the rest of the standard library, such as for sleep:

use std::thread;
use std::time::Duration;

thread::sleep(Duration::from_secs(1));

…but apart from that, I don’t use it for much else. If I had to touch any sort of date calculations, I would defer to an external crate such as chrono or time.

Summary

As you can see, my list of warts in the Rust standard library is quite short. Given that Rust 1.0 was released more than a decade ago, the standard library has held up really well. That said, I reserve the right to update this article in case I become aware of additional sharp edges in the future.

In general, I like that Rust has a relatively small standard library because once a feature is in there it stays there forever. ⁴

2025-05-17 08:00:00

Some people learn new programming languages best by looking at examples for how to do the same thing they know in one language is done in the other. Below is a syntax comparison table which can serve as a quick reference for common C++ constructs and their equivalents in Rust. It is not a comprehensive guide, but I hope it helps out a C++ developer looking for a quick reference to Rust syntax.

Comparing Idioms in Rust and C++

fn add(first: i32, second: i32) -> i32 {
    first + second
}

int add(int first, int second) {
    return first + second;
}

fn add(a: i32, b: i32) -> i32 { a + b }

auto add(int a, int b) -> int { return a + b; }

struct Person {
    id: u32,
    health: i32
}

struct Person {
    unsigned int id;
    int health;
};

impl MyClass {
    fn new(name: &String, data: &Vec) -> Self {
        // ...
    }
}

// Usually split between header (.h) and implementation (.cpp)
// Header:
class MyClass {
public:
    MyClass(const string& name, 
            const vector& data);
};
// Implementation:
MyClass::MyClass(const string& name, 
                const vector& data) {
    // ...
}

fn get_name(&self) -> String {
    self.name.clone()
}

string get_name() const {
    return name; // 'this' is implicit in C++
}

trait Shape {
    fn get_area(&self) -> f64;
}

class Shape {
public:
    virtual double get_area() const = 0;
};

impl Shape for Circle {
    fn get_area(&self) -> f64 {
        // ...
    }
}

class Circle : public Shape {
public:
    double get_area() const override {
        // ...
    }
};

fn generic_call(gen_shape: &T) {
    // ...
}

template
void generic_call(const T& gen_shape) {
    // ...
}

trait Shape {
    type InnerType;
    fn make_inner(&self) -> Self::InnerType;
}

// C++20 concepts approach
template
concept Shape = requires(T t) {
    typename T::InnerType;
    { t.make_inner() } -> 
        std::convertible_to;
};

enum MyShape {
    Circle(f64),
    Rectangle(f64, f64)
}

// Must specify contained types
std::variant my_shape;
// Uses integer tags rather than named variants

match shape {
    MyShape::Circle(r) => // ...,
    MyShape::Rectangle(w, h) => // ...
}

std::visit(overloaded {
    [](const Circle& c) { /* ... */ },
    [](const Rectangle& r) { /* ... */ }
}, my_shape);

// Manual allocation
let boxed = Box::new(value);
// Explicit non-trivial copies
let s = String::from("text");
let owned = borrowed.to_owned();
let cloned = original.clone();

// Manual allocation
auto* ptr = new T();
// Smart pointers
auto unique = std::make_unique();
auto shared = std::make_shared();
// Implicit non-trivial copies when passing by value
auto copy = original; // May implicitly copy

impl Drop for MyType {
    fn drop(&mut self) {
        // cleanup
    }
}

~MyType() {
    // cleanup
}

Rust vs C++ Type Equivalents

u8, u16, u32, u64, u128, usize

uint8_t, uint16_t, uint32_t, uint64_t, 
__uint128, uintptr_t/size_t

i8, i16, i32, i64, i128, isize

int8_t, int16_t, int32_t, int64_t, 
__int128, intptr_t/ptrdiff_t

2025-05-15 08:00:00

Up until a few years ago, Python tooling was a nightmare: basic tasks like installing packages or managing Python versions was a pain. The tools were brittle and did not work well together, mired in a swamp of underspecified implementation defined behaviour.

Then, apparently suddenly, but in reality backed by years of ongoing work on formal interoperability specifications, we saw a renaissance of new ideas in the Python ecosystem. It started with Poetry and pipx and continued with tooling written in Rust like rye, which later got incorporated into Astral.

Astral in particular contributed a very important piece to the puzzle: uv – an extremely fast Python package and project manager that supersedes all previous attempts; For example, it is 10x-100x faster than pip.

2025-05-05 08:00:00

I see people make the same mistakes over and over again when learning Rust. Here are my thoughts (ordered by importance) on how you can ease the learning process. My goal is to help you save time and frustration.

Let Your Guard Down

Stop resisting. That’s the most important lesson.

Accept that learning Rust requires adopting a completely different mental model than what you’re used to. There are a ton of new concepts to learn like lifetimes, ownership, and the trait system. And depending on your background, you’ll need to add generics, pattern matching, or macros to the list.

Your learning pace doesn’t have much to do with whether you’re smart or not or if you have a lot of programming experience. Instead, what matters more is your attitude toward the language.

I have seen junior devs excel at Rust with no prior training and senior engineers struggle for weeks/months or even give up entirely. Leave your hubris at home.

Treat the borrow checker as a co-author, not an adversary. This reframes the relationship. Let the compiler do the teaching: for example, this works great with lifetimes, because the compiler will tell you when a lifetime is ambiguous. Then just add it but take the time to reason about why the compiler couldn’t figure it out itself.

fn longest(x: &str, y: &str) -> &str {
    if x.len() > y.len() {
        x
    } else {
        y
    }
}

If you try to compile this, the compiler will ask you to add a lifetime parameter. It provides this helpful suggestion:

1 | fn longest<'a>(x: &'a str, y: &'a str) -> &'a str {
  |           ++++     ++          ++          ++

So you don’t have to guess what the compiler wants and can follow its instructions. But also sit down and wonder why the compiler couldn’t figure it out itself.

Most of the time when fighting the compiler it is actually exposing a design flaw. Similarly, if your code gets overly verbose or looks ugly, there’s probably a better way. Declare defeat and learn to do it the Rust way.

If you come from a dynamic language like Python, you’ll find that Rust is more verbose in general. Most of it just comes from type annotations, though. Some people might dismiss Rust as being “unelegant” or “ugly”, but the verbosity actually serves a good purpose and is immensely helpful for building large-scale applications:

• First off, you will read the code more often than you write it, which means type annotations will give you more local context to reason with.
• Second, it helps immensely with refactoring because the compiler can check if you broke any code while you move things around. If your code turns out to look very ugly, take a step back and ask if there’s a simpler solution. Don’t dismiss the language right away.

Turn on all clippy lints on day one – even the pedantic ones. Run the linter and follow the suggestions religiously. Don’t skip that step once your program compiles.

Resistance is futile. The longer you refuse to learn, the longer you will suffer; but the moment you let your guard down is the moment you’ll start to learn. Forget what you think you knew about programming and really start to listen to what the compiler, the standard library, and clippy are trying to tell you.

Baby Steps

I certainly tried to run before I could walk. That alone cost me a lot of precious time.

Don’t make it too hard on yourself in the beginning. Here are some tips:

• Use String and clone() and unwrap generously; you can always refactor later – and refactoring is the best part about Rust! I wrote an article on saving yourself time during that phase here.
• Use simple if or match statements before starting to learn some of the more idiomatic .and_then etc. combinators
• Avoid async Rust in week 1. The additional rules are a tax on people still learning the core ownership model.

Don’t introduce too many new concepts at the same time! Instead, while you learn about a new concept, have an editor open and write out a few examples. What helped was to just write some code in the Rust playground and try to get it to compile. Write super small snippets (e.g., one main.rs for one concept) instead of using one big “tutorial” repo. Get into the habit of throwing most of your code away.

I still do that and test out ideas in the playground or when I brainstorm with clients.

For instance, here’s one of my favorite code snippets to explain the concept of ownership:

fn my_func(v: String) {
    // do something with v
}

fn main() {
    let s = String::from("hello");
    my_func(s);
    my_func(s); // error, but why?
}

Can you fix it? Can you explain it? Ask yourself what would change if v was an i32.

If Rust code looks scary to you, break it down. Write your own, simpler version, then slowly increase the complexity. Rust is easier to write than to read. By writing lots of Rust, you will also learn how to read it better as well.

Be Accurate

How you do anything is how you do everything. – An ancient Rust proverb

You can be sloppy in other languages, but not in Rust. That means you have to be accurate while you code or the code just won’t compile. The expectation is that this approach will save you debugging time in the future.

I found that the people who learn Rust the fastest all have great attention to detail. If you try to just get things done and move on, you will have a harder time than if you aim to do things right on your first try. You will have a much better time if you re-read your code to fix stupid typos before pressing “compile.” Also build a habit of automatically adding & and mut where necessary as you go.

A good example of someone who thinks about these details while coding is Tsoding. For example, watch this stream where he builds a search engine in Rust from scratch to see what I mean. I think you can learn this skill as long as you’re putting in your best effort and give it some time.

Don’t Cheat

With today’s tooling it is very easy to offload the bulk of the work to the computer. Initially, it will feel like you’re making quick progress, but in reality, you just strengthen bad habits in your workflow. If you can’t explain what you wrote to someone else or if you don’t know about the tradeoffs/assumptions a part of your code makes, you took it too far.

Often, this approach stems from a fear that you’re not making progress fast enough. But you don’t have to prove to someone else that you’re clever enough to pick up Rust very quickly.

Walk the Walk

To properly learn Rust you actually have to write a lot of code by hand. Don’t be a lurker on Reddit, reading through other people’s success stories. Have some skin in the game! Put in the hours because there is no silver bullet. Once it works, consider open sourcing your code even if you know it’s not perfect.

Don’t Go on Auto-Pilot

LLMs are like driving a car on auto-pilot. It’s comfortable at first, but you won’t feel in control and slowly, that uneasy feeling will creep in. Turn off the autopilot while learning.

A quick way to set you up for success is to learn by writing code in the Rust Playground first. Don’t use LLMs or code completion. Just type it out! If you can’t, that means you haven’t fully internalized a concept yet. That’s fine! Go to the standard library and read the docs. Take however long it takes and then come back and try again.

Slow is steady and steady is fast.

Build Muscle Memory

Muscle memory in programming is highly underrated. People will tell you that this is what code completion is for, but I believe it’s a requirement to reach a state of flow: if you constantly blunder over syntax errors or, worse, just wait for the next auto-completion to make progress, that is a terrible developer experience.

When writing manually, you will make more mistakes. Embrace them! These mistakes will help you learn to understand the compiler output. You will get a “feeling” for how the output looks in different error scenarios. Don’t gloss over these errors. Over time you will develop an intuition about what feels “rustic.”

Predict The Output

Another thing I like to do is to run “prediction exercises” where I guess if code will compile before running it. This builds intuition. Try to make every program free of syntax errors before you run it. Don’t be sloppy. Of course, you won’t always succeed, but you will get much better at it over time.

Try To Solve Problems Yourself, Only Then Look Up The Solution.

Read lots of other people’s code. I recommend ripgrep, for example, which is some of the best Rust code out there.

Develop A Healthy Share Of Reading/Writing Code.

Don’t be afraid to get your hands dirty. Which areas of Rust do you avoid? What do you run away from? Focus on that. Tackle your blind spots. Track your common “escape hatches” (unsafe, clone, etc.) to identify your current weaknesses. For example, if you are scared of proc macros, write a bunch of them.

Break Your Code

After you’re done with an exercise, break it! See what the compiler says. See if you can explain what happens.

Don’t Use Other People’s Crates While Learning

A poor personal version is better than a perfect external crate (at least while learning). Write some small library code yourself as an exercise. Notable exceptions are probably serde and anyhow, which can save you time dealing with JSON inputs and setting up error handling that you can spend on other tasks as long as you know how they work.

Build Good Intuitions

Concepts like lifetimes are hard to grasp. Sometimes it helps to draw how data moves through your system. Develop a habit to explain concepts to yourself and others through drawing. I’m not sure, but I think this works best for “visual”/creative people (in comparison to highly analytical people).

I personally use excalidraw for drawing. It has a “comicy” feel, which takes the edge off a bit. The implication is that it doesn’t feel highly accurate, but rather serves as a rough sketch. Many good engineers (as well as great Mathematicians and Physicists) are able to visualize concepts with sketches.

In Rust, sketches can help to visualize lifetimes and ownership of data or for architecture diagrams.

Build On Top Of What You Already Know

Earlier I said you should forget everything you know about programming. How can I claim now that you should build on top of what you already know?

What I meant is that Rust is the most different in familiar areas like control flow handling and value passing. E.g., mutability is very explicit in Rust and calling a function typically “moves” its arguments. That’s where you have to accept that Rust is just different and learn from first principles.

However, it is okay to map Rust concepts to other languages you already know. For instance, “a trait is a bit like an interface” is wrong, but it is a good starting point to understand the concept.

Here are a few more examples:

• “A struct is like a class (minus the inheritance)”
• “A closure is like a lambda function (but it can capture variables)”
• “A module is like a namespace (but more powerful)”
• “A borrow is like a pointer (but with single owner).”

And if you have a functional background, it might be:

• “Option is like the Maybe monad”
• “Traits are like type-classes”
• “Enums are algebraic data types”

The idea is that mapping concepts helps fill in the gaps more quickly.

Map what you already know from another language (e.g., Python, TypeScript) to Rust concepts. As long as you know that there are subtle differences, I think it’s helpful.

I don’t see people mention this a lot, but I believe that Rosetta Code is a great resource for that. You basically browse their list of tasks, pick one you like and start comparing the Rust solution with the language you’re strongest in.

Also, port code from a language you know to Rust. This way, you don’t have to learn a new domain at the same time as you learn Rust. You can build on your existing knowledge and experience.

• Translate common language idioms from your strongest language to Rust. E.g., how would you convert a list comprehension from Python to Rust? Try it first, then look for resources, which explain the concept in Rust. For instance, I wrote one on this topic specifically.
• I know people who have a few standard exercises that they port to every new language they learn. For example, that could be a ray-tracer, a sorting algorithm, or a small web app.

Finally, find other people who come from the same background as you. Read their blogs where they talk about their experiences learning Rust. Write down your experiences as well.

Don’t Guess

I find that people who tend to guess their way through challenges often have the hardest time learning Rust.

In Rust, the details are everything. Don’t gloss over details, because they always reveal some wisdom about the task at hand. Even if you don’t care about the details, they will come back to bite you later.

For instance, why do you have to call to_string() on a thing that’s already a string?

my_func("hello".to_string())

Those stumbling blocks are learning opportunities. It might look like a waste of time to ask these questions and means that it will take longer to finish a task, but it will pay off in the long run.

Reeeeeally read the error messages the compiler prints. Everyone thinks they do this, but time and again I see people look confused while the solution is right there in their terminal. There are hints as well; don’t ignore those. This alone will save you sooo much time. Thank me later.

You might say that is true for every language, and you’d be right. But in Rust, the error messages are actually worth your time. Some of them are like small meditations: opportunities to think about the problem at a deeper level.

If you get any borrow-checker errors, refuse the urge to guess what’s going on. Instead of guessing, walk through the data flow by hand (who owns what and when). Try to think it through for yourself and only try to compile again once you understand the problem.

Lean on Type-Driven Development

The key to good Rust code is through its type system.

It’s all in the type system. Everything you need is hidden in plain sight. But often, people skip too much of the documentation and just look at the examples.

What few people do is read the actual function documentation. You can even click through the standard library all the way to the source code to read the thing they are using. There is no magic (and that’s what’s so magical about it).

You can do that in Rust much better than in most other languages. That’s because Python for example is written in C, which requires you to cross that language boundary to learn what’s going on. Similarly, the C++ standard library isn’t a single, standardized implementation, but rather has several different implementations maintained by different organizations. That makes it super hard to know what exactly is going on. In Rust, the source code is available right inside the documentation. Make good use of that!

Function signatures tell a lot! The sooner you will embrace this additional information, the quicker you will be off to the races with Rust. If you have the time, read interesting parts of the standard library docs. Even after years, I always learn something when I do.

Try to model your own projects with types first. This is when you start to have way more fun with the language. It feels like you have a conversation with the compiler about the problem you’re trying to solve.

For example, once you learn how concepts like expressions, iterators and traits fit together, you can write more concise, readable code.

Once you learn how to encode invariants in types, you can write more correct code that you don’t have to run to test. Instead, you can’t compile incorrect code in the first place.

Learn Rust through “type-driven development” and let the compiler errors guide your design.

Invest Time In Finding Good Learning Resources

Before you start, shop around for resources that fit your personal learning style. To be honest, there is not that much good stuff out there yet. On the plus side, it doesn’t take too long to go through the list of resources before settling on one specific platform/book/course. The right resource depends on what learner you are. In the long run, finding the right resource saves you time because you will learn quicker.

I personally don’t like doing toy exercises that others have built out for me. That’s why I don’t like Rustlings too much; the exercises are not “fun” and too theoretical. I want more practical exercises. I found that Project Euler or Advent of Code work way better for me. The question comes up quite often, so I wrote a blog post about my favorite Rust learning resources.

Don’t Just Watch YouTube

I like to watch YouTube, but exclusively for recreational purposes. In my opinion, watching ThePrimeagen is for entertainment only. He’s an amazing programmer, but trying to learn how to program by watching someone else do it is like trying to learn how to become a great athlete by watching the Olympics. Similarly, I think we all can agree that Jon Gjengset is an exceptional programmer and teacher, but watching him might be overwhelming if you’re just starting out. (Love the content though!)

Same goes for conference talks or podcasts: they are great for context, and for soft-skills, but not for learning Rust.

Instead, invest in a good book if you can. Books are not yet outdated and you can read them offline, add personal notes, type out the code yourself and get a “spatial overview” of the depth of the content by flipping through the pages.

Similarly, if you’re serious about using Rust professionally, buy a course or get your boss to invest in a trainer. Of course, I’m super biased here as I run a Rust consultancy, but I truly believe that it will save you and your company countless hours and will set you up for long-term success. Think about it: you will work with this codebase for years to come. Better make that experience a pleasant one. A good trainer, just like a good teacher, will not go through the Rust book with you, but watch you program Rust in the wild and give you personalized feedback about your weak spots.

Find A Coding Buddy

“Shadow” more experienced team members or friends.

Don’t be afraid to ask for a code review on Mastodon or the Rust forum and return the favor and do code reviews there yourself. Take on opportunities for pair programming.

Explain Rust Code To Non-Rust Developers

This is such a great way to see if you truly understood a concept. Don’t be afraid to say “I don’t know.” Then go and explore the answer together by going straight to the docs. It’s way more rewarding and honest.

Help out with OSS code that is abandoned. If you put in a solid effort to fix an unmaintained codebase, you will help others while learning how to work with other people’s Rust code.

Read code out loud and explain it. There’s no shame in that! It helps you “serialize” your thoughts and avoid skipping important details.

Take notes. Write your own little “Rust glossary” that maps Rust terminology to concepts in your business domain. It doesn’t have to be complete and just has to serve your needs.

Write down things you found hard and things you learned. If you find a great learning resource, share it!

Believe In The Long-Term Benefit

If you learn Rust because you want to put it on your CV, stop. Learn something else instead.

I think you have to actually like programming (and not just the idea of it) to enjoy Rust.

If you want to be successful with Rust, you have to be in it for the long run. Set realistic expectations: You won’t be a “Rust grandmaster” in a week but you can achieve a lot in a month of focused effort. There is no silver bullet, but if you avoid the most common ways to shoot yourself in the foot, you pick up the language much faster. Rust is a day 2 language. You won’t “feel” as productive as in your first week of Go or Python, but stick it out and it will pay off. Good luck and have fun!

2025-05-01 08:00:00

We don’t usually think much about Webhooks – at least I don’t. It’s just web requests after all, right? In reality, there is a lot of complexity behind routing webhook requests through the internet.

What if a webhook request gets lost? How do you know it was received in the first place? Can it be a security issue if a webhook gets handled twice? (Spoiler alert: yes)