I have a routine of reading a Rust book every evening after work. I meticulously interpret what I read, add them as comments in the code, and apply the examples. Since I already have a background in C#, PHP, and Python, I skipped practicing some of the earlier, more basic sections.
I finished the 'Lifetimes' topic yesterday and am starting 'Closures' today. A few days ago, I completed 'Error Handling' and tried to put those concepts into practice for the first time yesterday. While I made good progress, I did get confused and struggled in certain parts, eventually needing a bit of AI assistance.
To be honest, I initially felt really discouraged and thought I wasn't learning effectively when I hit those roadblocks. However, I’ve realized that making mistakes and learning through trial and error has actually helped me internalize the concepts—especially error handling—much better. I wonder if anyone else has gone through a similar emotional rollercoaster?
Now that I'm nearing the end of the book, I want to shift from theory to practice. Could you recommend any project ideas that would help me reinforce what I've learned in Rust?
One last question: Sometimes I get the feeling that I should go back and read the whole book from the very beginning. Do you think I should do that, or is it better to just keep moving forward with projects?
Yes. Software engineering is a craft. You create stuff. Creating stuff (aka trial and error) is the most effective way to get better at creating stuff, even if it gets messy at times. At least that is my experience.
Sure have. Countless times over the decades. Always there is new language to learn, or a new OS etc, that's before you get confronted with some huge unknown code base that you have to work on. That's what the life of a software engineer is. It's all very humbling.
You are right, learning by doing is where you have to go, experiment with code, change things here and there.
I find it hard to suggest any project ideas, that rather depends on your experience and skills aside from whatever languages you have experience in. Perhaps you can find some not so large thing, or small part of a bigger thing, that you have implemented before in C#, PHP, Python whatever and think about how you would implement it in Rust. Then at least your attention is on Rust rather than saving whatever problem it is because you have done that before.
By means read the book again, or again and again. But at the same time get on with that code project. That will concentrate your mind and make things stick.
Don't make the mistake and read the official tutorial book twice. I actually made that mistake -- I started learning Rust with the official original book, and one year later I thought I could read the variant from Brown University just for fun again. But it was really no fun to read all that quite verbose explanations again. You might just read a different book. I am currently reading "Effective Rust", which is a good summary and repetition of the important Rust concepts, it is also freely available online. Or wait for the third Edition of "Programming Rust" by Jim Blandy, that one should be available soon. The Book of Jon Gjengset is also an option, but it has not many code examples, it is more for some background explanations. But yes, to really learn Rust, you have to actually write code in it. Rust is not too difficult, but complex, so it needs practice.
I'm gonna be real honest. I've never struggled with learning a programming language as much as I did with Rust. I went through the thing that I've heard some others say they went through: I gave Rust a try, was severely confused and simply gave up. A few days later I thought "I haven't given up on any programming language before, and I'm not about to do it now", and gave it another try. It took a while, but eventually things started to click.
For me, it took a long time before I felt I could be productive in Rust. But in the end, the struggle was definitely worth it. I've shipped a lot of Rust code, and it has not only been surprisingly stable, but it was also been very fun to write.
I didn't use The Book, I used the the first edition of the O'Reilly Rust Programming. But I did go back and started reading it from the start again. In fact, I think I did it more than once. For me, it was helpful to reread the book.
The way I got started with actual projects was:
I wrote small, isolated, helper tools -- things I could finish in less than a day.
I ported my own tools/libraries from C and C++. The basic idea was that I had already sorted out the application logic, so I wouldn't need to battle both figuring out the logic and learn Rust at the same time. In retrospect, this had a not-so-good side-effect: Since I was looking at C and C++ code, I was trying very much to write C-in-Rust -- which works, but I wish I had learned more idiomatic Rust in the beginning.
For me, the story is a bit different: I started learning Rust not long after 1.0 had been released in 2015 (wow it's been almost 11 years already), which did present its own challenges relative to current-day Rust, mostly in the form of a more restrictive version of borrowck as well as the fact that async hadn't been added yet.
But there was also a lot less to learn back then, and the promise of an elegant resource management system (aka GC + automatic cleanup for resources e.g. files) without some runtime algorithm consuming CPU cycles and RAM as well as introducing latency was very compelling to me. So I just got started on it, wrote some pretty crappy code, and learned a bunch along the way.
After that initial hump, the rest mostly comes down to reading the release notes when a new version is released i.e. it's just incremental learning.
That phrase severely confuses me, because Rust is not that strange. It's usually the languages that use some pretty non-mainstream paradigms that cause people trouble: Forth, Haskell, Prolog, REFAL, maybe APL or LISP (although these are more mainstream). How was your experience learning any of these?
That's why I was berating myself when I, finally, started learning Rust: the whole book doesn't mention any advanced concepts (things like HRBTs are conveniently not included), while learning how to deal with borrow checker took some time, obviously, it wasn't problem with the concept, itself, more with an implementation — and to have trouble with that you have to write code, just reading the book is not enough to hit awkward corner cases…
Unlikely such project exists. The best approach for many people, just start programing in Rust. Your skills will be shaped with time. It took over two years for me to start understand something about Rust. Hopefully it will be much faster for you. But my recommendation remains the same, prepare to be patient. Many my frinds dropped Rust after 6 months because they expected faster results.
I'm far from a Rust expert but here's three pieces of advice:
I found that working on a project I was genuinely interested in (in my case a search engine) really helped me maintain motivation. We can give you project ideas but without knowing your interests and areas of expertise, it will be difficult to recommend something. For example I have little interest in writing a digital to audio convertor, but that might be something that you are excited about! That said it might be helpful to pick a project that avoids parts of Rust that add complexity like async and cyclical ownership.
Give your error messages to ChatGPT. I treated ChatGPT like a very patient Rust mentor and I would only give an error message or a very simplified snippet of code rather than the entire project. This allowed me to isolate the part of Rust I wasn't understanding, play around with some examples to solidify my understanding, and then translate what I learned to my project. Sometimes ChatGPT is wrong and that's why it's important that you end up writing the final fix for your project rather than just blindly copying it into your code. The fact the Rust compiler is so strict really helps to enforce that what ChatGPT gives you is reasonable but it's up to you to check it makes sense. Sometimes that means reading docs or returning to the book.
Avoid lifetimes at first. Just use borrows and if you have to, clone() something. Since you aren't writing production code, the small performance hit is ok. Once you are more comfortable you can revisit and remove the clone()s.
I would recommend jumping in and coding something rather than doing more reading
Here is a simple project approach idea - take an algorithm you know or want to know and apply it to Rust. For instance, take the trending Ralph agentic loops everyone is doing in shell/python and use a framework like ADK-Rust to achieve the same. Or start with a scientific calculator, which in rust is not as easy or as straightforward to implement.
I think learning Rust if you don't know about programming should be easier than learning Rust if you already have a lot of experiance in other programming languages. Especially if you have experiance with only managed memory programming languages like C#, PHP and Python.
Lifetimes is hard, because it is hard to track lifetime of variable in your head. In C# it is done automatically by C#. And in c/c++ this makes half of bugs related to memory
I like error handling in Rust and I hate Exceptions in C# because I always forget to catch exceptions or don't know that exceptions can be thrown. If you don't handle exceptions it is easy to write program, because you always use right data so it works perfectlly without any error handling. But situation change a lot if you give app to other people to use. But in Rust you must handle all errors all time. It makes beter app, but more work.
In my case, I can't do any project I will not use or others will not use. This is why all my projects are about my work. I write something I myself will use for my work, or my coworkers wil use.
Sometimes it is good to watch videos too. I like this video
This video has good view about Rust. Rust is not OOP, nor procedural programming. Rust is type system proghramming.
To create right type for your data is hardest part in Rust.
Learning Rust is very different from learning say "C". It can feel frustrating when Rust doesn't allow you to program the way you are used to. Eventually the Rust paradigm starts to become more intuitive as you write more code and start solving problems, but don't expect this to happen in a few days. Once you get the hang of it though it is very nice.
It is kind of like a wikipedia.
You can trust it, if it is correct, but is it correct? Best to research any of the answers you get from a wiki before trusting them.
That said, it can give you wrong answers and you may waste some time verifying them. But you will also save some time getting correct answers that you can verify are correct.
Learning C is very different from learning say "Rust". It can feel frustrating when C allows you to program any old how and your mistakes silently compile then crash at run time. Eventually the C paradigm starts to become more intuitive as you write more code and start debugging problems, but don't expect this to happen in a few days.
See what I did there?
I'm not entirely joking. I recall being very frustrated with the endless crashes of C and data corruptions when I first started using it in 1982. Without any compiler error or warning. I had previous experience of ALGOL68 where that was rare.
More seriously, what I'm getting at is that C and Rust are very similar. The difference being where your mistakes show up. One has to learn those rules about types and lifetimes in both languages. You can do it the easy way with Rust and compiler errors, or the hard way with C and a debugger.
Yes, I can remember that, when I had to use C for my diploma thesis (Using an old measurement card in an old Win 3.1 PC with 18 MB RAM, recording data for am custom build Fourier-Spectrometer), after using Modula 2 and Oberon at home for a few years. Well, if I remember correctly, Borland-Pascal would have been an option as well, but I decided to use Watcom-C that time.
Oh, fond memories, I loved the Watcom-C for a while. What a treat to write 32 bit code when running under 16 bit MS-DOS. By then I had learned most of the ways to mess up in C and how to avoid them. Most...
