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

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.