Really hard question to answer simply. They're two languages that are at very opposite ends of the spectrum, yet they can usually both accomplish the same goal. I think the main difference is that Rust is significantly faster and uses less memory in the majority of cases, but also harder to learn and to reason about. Good package manager, tooling, etc, is a nice to have.

Python focuses on being simple, interpreted and dynamicaly typed, Rust requires you to specify the exact types of all the things (like C/C++) which allows it to generate really optimal compiled machine code before execution, it has more information to work with. Accessing a struct/"object" field is not a hash table lookup, it's a direct pointer access, as the exact size of things are known at compilation time.

If you're writing a script, a tool, a small game, it's simpler to use Python. If you're writing a database engine, a mission-critical piece of code that has to behave predictably without the possibility of random GC pauses, anything that has realtime constraints such as audio, lower-level languages like C, C++ and Rust are a must.

A lot of higher-level folk seem to enjoy Rust as well, especially in networking/the web, for whom the speed is worth the additional difficulty and complexity.

Speed is obviously the main one. I know that's not normally seen as so valuable in Python land because there's more of a focus on optimising the hot path rather than the entire codebase, but starting out in a fast language can give you a lot of flexibility in terms of performance later on. For example, I tried to enabled gzip encoding for responses in a Python web app recently, and it just turned out to be too much for the system to handle. But an experimental rewrite of the same project in Rust was so much more performant, that, had we gone down that route, we'd have probably been able to compress our responses considerably. This is what I mean by flexibility: by having all-round great performance, you can fit more stuff in before you need to start worrying about optimisation.

There's also type safety. Not just in terms of having strict compile-time types, but also in what those types can actually do for you. With enums, for example, you can specify different states, but also which data is available in those states. For example, you might model messages passed between different nodes as an enum, where one message contains the current date, and another message contains the number of active users. This way, the compiler proves that you can't end up in impossible situations: having a "date" message that doesn't have an attached Datetime instance, say.

Finally, the developer tooling is often leagues ahead of Python. It's possible to get by in Python with venvs, pip, maybe a requirements file, and so on. But there are often a lot of edge cases that this setup doesn't cover, so there's a lot of this party tools to cover up sharp edges - pip-tools, Poetry, etc. And even then, you often end up in odd situations, particularly if you're trying to retrofit these features onto an existing system.

In the meantime, cargo Just Works™. As in, cargo itself covers 90% of the cases I run into (managing dependencies, managing multiple projects, running tests, building, etc), and the 10% is usually very easy to add: cross compiling with the `cross` tool, linting with `clippy`, IDE support with `rust-analyzer` etc. Managing a Rust project is just so much easier than managing a Python project.

Different people will probably say different things, but as someone who used to be a big fan of Python, but now tends to use Rust for most side projects, those were the big advantages that did it for me.

Without having actually written any Rust, but being familiar with it and having written a fair bit of Python, the most obvious ones are: speed & static binaries, with cargo+crates coming a close second.

Bragging rights