I keep seeing "how to learn X" and a series of tutorials, exercises, or courses.
Maybe it's me, but each time I learned something, it was by doing projects. Usually, starting with modifying someone's code (while seeing a language for the first time) and then reading a tutorial to understand what's going on.
It gave two things - a context of an actual project (especially as usually ecosystem is more important, and tricky, than the language itself) and motivation.
Otherwise, I either stop learning (which often is a good thing because it turns out I don't need this language or tech) or don't internalize the most important things.
That's exactly what "Zero To Production" is about. Actually most of what makes Rust intro material good is that you are building things, not just going on about syntax and language particulars.
For example, "The Book" (what we call "The Rust Programming Language") ends with building a multi-threaded web-server.
The official Rust introduction is stellar!
One concept at a time, clearly explained, with examples.
And, most importantly, it is complete. It starts with how to install it, and the installation actually works in a few lines of code. The authors put a lot of effort into the general onboarding user experience.
Coming from a C++ background, learning Python required a trial-and-error process similar to what you've described. However, learning Groovy while knowing Python and Java took only a single pass through the Groovy docs - just to figure out what exact elements of Python and Java has Groovy incorporated in what way.
In context of tutorials, a lot of people write them "for themselves" without realizing it - there's just too much implicit knowledge assumed. And it's hard work to expand on all of it, without going down the rabbit hole and ending up explaining the concept of Turing Machines.
I love how culty the Rust sphere is. I don't have many opportunities to use it but I always stop to watch tutorials/read articles because of how enthusiastic people are about the language
To quote Maria Bamford, "Sure I'll join your cult!"
The world needs languages that try to be both safe and high performance. Rust is taking a shot at it. I'm not actually using it myself, but when I see people getting excited about it, I'm not laughing at them. I'm thinking that I get where they're coming from.
From the analytical trends and tooling it's passed the hump of mainstream in the sense that it can be used for prod. It's sort of culty still but it's no longer a niche thing anymore and very usable.
The only avenue that it has yet to penetrate is gaming. No other language has achieved this yet, and rust is the closest.
Aside from using Rust as a Python developer with extensive outdated C/C++ experience, I'm really tempted to dive into Zig for all what it's praised for, but nim's hot code reloading [0] feature is so very tempting to me, that I'm not sure if choosing Zig would be a mistake. I do this constantly in Python and would love Rust to have this included in some easy to handle way.
In any case, I'm totally happy with Rust, and apart from the missing hot code reloading, it's so enjoyable to code in.
Hah, yeah. I'm silly that way. I don't like that it doesn't have macros. It's not something I need to look into at the moment anyway. I'd probably never find a use case for it.
Except that zig is really really really not production ready. It has major bugs pretty much everywhere and fundamental stuff breaks/changes every other month.
comptime is cool, and I see a future for zig or its ideas, but not in less than 5 years.
I am still trying to figure out how to jump on that bandwagon. I used to be a C++ super geek but lately it’s mostly C# and Python. They are way more practical and productive but for some reason I like complex languages.
Not OP but imho as soon as possible; whatever major understanding pieces you are lacking you will have to learn while making the project.
There are also language concepts that will not make much sense when learning without context from a book, but will make much more sense after attempting to write something without using that first.
I wouldn't treat it as a binary. Use the project to provide feedback on what learning material to read, then go back to the project until you hit another blocker.
Suppose you're read a book about Rust and now you want to write a web service. You take a peek on Reddit and hear good things about Axum, so you check out its docs.
You write some handlers that do crud operations on a database, and it's all going well. You can translate the examples in the docs into your code in a pretty straightforward way.
Then you decide you want live chat. You've heard of websockets, and axum has a websocket example. But you keep beating your head against the compiler. What is the right type for a chat room? Who owns the chat rooms?
You realize now would be a good moment to take a step back and learn more systemically. After reading through the tokio mini redis tutorial async makes a lot more sense and you're back on track.
In this example you "wasted" a little time before you took a step back and studied async more, but you saved significant time by tailoring your learning to what you needed. If you hadn't gotten partway into your project you might not have realized you'd want to learn async next and instead studied something else.
Just get the basics down for traits, borrowing and move semantics. Make sure you have thorough understanding of heap and stack. Once those are down you can move on to projects.
Rust is sufficiently complex that you have to do projects to encounter every nook and cranny of even the core language. Other language like python expertise in the language often involves knowing the libraries.
It gave two things - a context of an actual project (especially as usually ecosystem is more important, and tricky, than the language itself) and motivation. Otherwise, I either stop learning (which often is a good thing because it turns out I don't need this language or tech) or don't internalize the most important things.