Pythonistas we work with start to think about where data actually lives


Hey Reader,

Quick test. In this Python, where do numbers and `[1, 2, 3] live?

You probably know what it prints. Fewer Python devs can draw why:

Python never makes you draw this, because the runtime automatically tracks how many names point at that list and frees it when the count hits zero.

Now the equivalent example in Rust:

A `Vec` is a small fixed-size handle on the stack pointing at the real data on the heap.

Same for `String`.

So what happens here?

Rust copied the three-field handle and invalidated `numbers`.

Nothing was freed, nothing was copied on the heap.

In a recent Rust demo I admittedly said "A is freed up" after a move while teaching. This is the picture I should have had in my head.

And it's why Rust needs no garbage collector: there is exactly one owner, so the compiler knows the exact line where `[1, 2, 3] can be freed.

Python lets you ignore the question "who owns this?"

Rust requires you to answer it.

Without the picture, the rules feel like arbitrary compiler pedantry.

With it, they're just the compiler asking you to be explicit about something Python always did for you, but came with a hit to performance and sometimes safety.

(This is a mental model, not a full account of CPython or Rust internals. It's the model that makes the error messages start making sense.)

But here's also where it gets harder.

Moving ownership around works until you need two parts of your code to look at the same data.

In Python that's free. In Rust, that's called borrowing, and it's where most Python devs start fighting the compiler (no worries, in our cohort, they come out as best friends 🤝).


In week 3 of our cohort we dive deep into ownership, borrowing, and deciding between `String` and `&str, all in the context of building a real JSON parser from scratch.

You get a challenging project (good in AI times where we delegate more and more!), an engaging group, each PR reviewed by expert devs.

Learn new mental models. Learn an increasingly popular systems language.

Write better Python as a nice side-effect.

The next cohort starts in November → https://scriptertorust.com​

Cheers,

Bob & Jim


P.S. In the next email we’ll talk more about borrowing.

What `& actually points at, and why it can't outlive the owner.

Scripter to Rust

Level up your developer toolkit by bridging the gap between Python and Rust. Join Bob Belderbos and Jim Hodapp as they break down core Rust concepts. From memory management and ownership to building performant production tools. All taught step-by-step through a Python lens.

Read more from Scripter to Rust

Hey Reader, There are many great reasons to learn Rust 🦀 right now: ruff, uv, Pydantic, Polars - lot of tools moving to or rewriting their core in Rust. It's an elegant language with well designed patterns. It will change your mindset going back to Python (or other interpreted languages), the strictness is an eye-opener. LLMs/agents work better with Rust because Rust offers stricter guardrails. If AI writes too much of your code, maybe it's time for a fun challenge again for you? Why should...

Hey Reader, We’re seeing 3 trends that make Rust a strong contender moving forward: Developers want fast tooling. Hence many Python tools are now being rewritten in Rust. Developers are tired of runtime errors. Catching errors upfront can be painful at first, but it brings greater joy over time. LLMs need boundaries. Compiled languages provide strong guardrails for systems that are by nature nondeterministic. AI generated Rust code has fewer bugs. From Scripter to Rust Rust is amazing. It’s...