I am not a Rust programmer. I have shipped one small service in Rust in my life. I write mostly Go, occasionally Python, and, against my better judgement, sometimes Kotlin. And yet Rust is the language I most often recommend to engineers who tell me they want to get materially better at their craft.

The reason is not that Rust is going to take over the industry. It might, it might not, that's not the argument. The reason is that learning Rust properly forces you to hold a more accurate model of the computer in your head than most other mainstream languages ever require of you.

What Rust teaches that nothing else does

Four things, concretely:

1. Ownership as a first-class idea

Most languages hide ownership behind a garbage collector. Your code works because somebody else, somewhere, is reference-counting or tracing for you. Rust makes ownership a compile-time concept you have to name explicitly. Every value has an owner; every borrow is bounded; every shared reference is immutable by default.

Once you've internalised this, you start to see ownership bugs in your Python and Java and TypeScript. You notice shared mutable state where the rest of your team sees "just a field on the class". This is the single biggest reason I recommend the language.

2. Concurrency without hope

In Rust, a data race is a compile error. You cannot ship code that writes to a value from two threads without synchronisation. You have to prove, to the compiler's satisfaction, that you've thought about it.

This is a pedagogical gold mine. After a month of writing Rust, you stop reaching for goroutine or Thread or asyncio.create_task() without first thinking about what's shared and whether it's guarded. That habit is worth the learning curve by itself.

3. Errors as values, not exceptions

The Result<T, E> type forces you to confront every failure point in your code. You either handle it or propagate it, explicitly. There is no silent swallow, no "I'll add a try/catch later", no catch-all that hides five real problems.

You won't love this at first. You'll find yourself typing ? a hundred times. After a while you'll realise that your error paths are now structurally present in the code rather than a set of assumptions you carry in your head. You will start resenting other languages for not giving you the same.

4. The compiler as a teacher

Rust's compiler is unusually good at telling you not just that you've made a mistake but what kind of mistake, where in your program, and how to fix it. Working with it is closer to a dialogue than a scolding. You will learn more about computers from three months of being told off by rustc than from a year of any bootcamp.

What this is not

I am not suggesting you switch languages at work. Most of you shouldn't. Most companies have no business rewriting working services in Rust. The cost is almost always higher than the benefit, in either engineering time or hiring pool. The existing language you use is probably fine.

The argument is about your own skill, not your employer's stack. Learning Rust on a side project, for an evening a week, will make you a better Python engineer than learning more Python will. That's the thing I actually believe.

How to learn it, practically

Skip the cheat sheets. Read the Rust book, cover to cover, once, slowly. Build one non-trivial project — a small HTTP server, a log parser, a game — that is not contrived. Write it idiomatically. If you are reaching for unsafe or Rc<RefCell<T>> in your first month, you're fighting the language and you will not learn the bit you came for.

It will be uncomfortable for the first two weeks. Around week four it clicks and you start to find your regular-job language a bit embarrassing for a while. Around week eight you get over yourself and go back to being a polyglot, but with a sharper model of what's going on underneath every new and every go.

Rust is not a career bet. It's a mental-model upgrade that happens to be packaged as a language.

— Nivaan