A simple blog made with Zola and Duckquill Zola 2026-07-31T00:00:00+00:00 https://vsyrakis.dev/tags/rust/atom.xml 2026-07-31T00:00:00+00:00 2026-07-31T00:00:00+00:00 Vasilios Syrakis https://vsyrakis.dev/blog/learning-rust-on-the-job/ <h1 id="rust-didn-t-click-for-me-until-after-i-worked-on-a-professional-project-with-it"><a class="zola-anchor" href="#rust-didn-t-click-for-me-until-after-i-worked-on-a-professional-project-with-it" aria-label="Anchor link for: rust-didn-t-click-for-me-until-after-i-worked-on-a-professional-project-with-it"><i class="icon"></i></a> Rust Didn’t Click For Me Until AFTER I Worked On A Professional Project With It</h1> <p>If you’ve ever tried to learn Rust, you probably know the standard playbook. You read “The Book” (the official Rust Programming Language book). You work through a bunch of code katas. You fight the borrow checker on toy problems, eventually forcing your code to compile, and you think, <em>“Okay, I get it now.”</em></p> <p>That was my story, too. I knew the syntax. I understood the theoretical difference between <code>String</code> and <code>&amp;str</code>. But if I’m being completely honest, Rust hadn’t actually <em>clicked</em>. It felt like I was solving academic puzzles rather than wielding a tool.</p> <p>It wasn’t until I had to maintain a professional, production-facing Rust project that the language truly made sense to me.</p> <h2 id="the-crossroads-python-vs-rust"><a class="zola-anchor" href="#the-crossroads-python-vs-rust" aria-label="Anchor link for: the-crossroads-python-vs-rust"><i class="icon"></i></a> The Crossroads: Python vs. Rust</h2> <p>The turning point came thanks to a well-scoped problem we encountered at work. A colleague of mine, who was also exploring Rust, decided to do a little experiment. They built a solution to this problem in Python—our team’s usual workhorse—and built an identical version in Rust.</p> <p>When the time came to hand the project over, they presented me with a choice: <em>“Here are the two versions. You get to choose which one you want to maintain.”</em></p> <p>The benchmarks made the decision almost obvious. The Rust version was blazing fast and consumed a fraction of the memory. Combine those performance metrics with my lingering, unresolved curiosity about the language, and my mind was made up. I chose to inherit the Rust codebase.</p> <h2 id="trial-by-maintenance"><a class="zola-anchor" href="#trial-by-maintenance" aria-label="Anchor link for: trial-by-maintenance"><i class="icon"></i></a> Trial by Maintenance</h2> <p>Taking ownership of that project changed everything. I wasn’t just writing greenfield code from scratch or solving isolated katas anymore. I was suddenly responsible for <em>maintaining</em> it.</p> <p>When you maintain a project, your priorities shift. My day-to-day involved:</p> <ol> <li><strong>Performance Tuning:</strong> Trying to squeeze even more speed out of the application, which forced me to deeply understand memory allocation and profiling in Rust.</li> <li><strong>Readability:</strong> This was the big one. I had to make the code readable not just for me, but for the rest of my team. Refactoring complex, nested logic into clean, idiomatic Rust forced me to stop just trying to “make it compile” and start writing code that communicated its intent clearly.</li> </ol> <p>Through this process, the borrow checker stopped being an adversary and started feeling like a very pedantic pair programmer. The rigid compiler rules, which previously felt restrictive in katas, suddenly revealed their value when I was trying to confidently refactor a critical piece of infrastructure without breaking it.</p> <h2 id="the-blueprint-effect"><a class="zola-anchor" href="#the-blueprint-effect" aria-label="Anchor link for: the-blueprint-effect"><i class="icon"></i></a> The Blueprint Effect</h2> <p>Months later, a requirement came up for a similar project. Rather than starting from zero, I used the first Rust project as a blueprint.</p> <p>Because I had spent so much time refining and maintaining that original codebase, I had a solid foundation. But this new project eventually grew larger and more complex than the first. As the scope expanded, I had to reach for more advanced Rust features. I was forced to design architectures that scaled, deal with more complex trait bounds, and manage concurrency in ways the first project didn’t require.</p> <p>Because I had that initial, well-scoped professional project under my belt, these new concepts weren’t overwhelming. They felt like natural extensions of what I already knew.</p> <h2 id="why-the-professional-context-matters"><a class="zola-anchor" href="#why-the-professional-context-matters" aria-label="Anchor link for: why-the-professional-context-matters"><i class="icon"></i></a> Why the Professional Context Matters</h2> <p>Looking back, books and katas are fantastic for syntax and foundational concepts. But they lack the friction of the real world.</p> <p>In a professional project, you can’t just slap a <code>.clone()</code> on everything to make the compiler shut up—eventually, a performance review or a team member will call you out on it. You have to write code that other people can read. You have to maintain it when requirements change.</p> <p>That constraint—the necessity of building something robust, performant, and legible for a team—was the crucible that finally made Rust click for me. It’s why I’m comfortable with the language today. If you’re stuck in the “kata phase” of learning Rust, my advice is to find a real, well-scoped problem at work and just build it. You might be surprised by how quickly the pieces fall into place.</p>