An almost religious case for Rust
The Rust community is known to be very passionate about Rust, and some even blame us for occasionally behaving like a cult. I’m afraid I will not dispel this notion, because in this article I’m going to make a case that Rust has made me a better engineer, a better manager and a better human being.
Background
My background is more than a decade of C# development. On the surface, before Rust, I had a great career: I’d been leading teams in successful projects and building software on the cutting edge of .NET. But deep inside I was never satisfied with what I’d been doing. I always thought it was impostor syndrome but, somehow, this feeling disappeared after I switched to Rust. It felt like magic; my somewhat apathetic state faded away and I rediscovered my love for software development. After prolonged self-reflection I found three key reasons behind the mood change.
The beauty of Rust
There have been more than enough articles on the technical aspects of how Rust compares to other languages, and I don’t want to repeat the same arguments. But all those brilliant ideas neatly put together was just the right thing to make me feel excited about software development again. I’m definitely not alone taking into account the amount of love Rust receives from engineers.
Open source community
Open source community in .NET has always felt very inactive in comparison to other, less centralized ecosystems. To be fair there’s been a lot of improvement over the past 5+ years since Microsoft started working on .NET Core and became more open source friendly but a lot of time has been lost. In contrast, the open source community in Rust is so healthy and vibrant, you naturally want to be a part of it. We’re working on open source trading infrastructure and plan to open source as much of our work as possible.
The types of projects
This argument will probably water down as Rust gets more mainstream but right now the quality of projects in Rust is outstanding: a lot of ambitious ideas are being implemented specifically in Rust.
Migration
I was running a fintech company. Things were going well but we were looking for ways to grow further. Taking into account we were working on high-load, latency-sensitive software, the idea of doing something serious in Rust had clear long-term benefits. Besides, it would make developers happy as we’ve had an increasing amount of Rust-curious engineers. And about two years ago (as soon as async/await support was stabilized) we started building the first Rust team.
Originally we did not plan it as a full migration from C# to Rust but, as soon as we started moving in this direction, there was no way to stop it. More and more developers started asking to move to the Rust team. Telling them ‘no’ and therefore demotivating them was definitely not the best option. So we’ve made a commitment to gradually migrate the vast majority of our software to Rust.
It’s probably hard to realize it now, when Rust seems more and more mainstream, but two years ago it was a very scary decision from the perspective of someone who runs a company. Moving from a comfort zone of a mature ecosystem you’ve been working in forever to a young ecosystem you have minimal experience with, was rough. But miserable failure was not an option, so we kept pushing forward. After the first couple months full of all kind of blocks, we saw surpisingly rapid improvements all around: our understanding of Rust was getting better day by day and Rust ecosystem was rapidly maturing.
There was definitely an element of gambling in how radical our migration to Rust was. But, fortunately, about half a year later, right when we started getting comfortable with a new ecosystem, Rust took off. Since then the only problem we’ve encountered was a narrow talent pool.
But even this problem ended up being kind of a good thing for us. While we were hiring in the mainstream languages, we always expected to get an experienced engineer who is a perfect fit right here and right now. Looking back at it, our hiring process was unnecessarily selfish and borderline arrogant. As there were basically no experienced Rust developers when we started, it pushed us to be more open-minded, to invest in people, to give chances and grow talent on our own. It improved our overall culture and made our teams more well-balanced. We follow this approach even now when there’s no drastic shortage of Rust developers anymore.
When I discuss our internal Rust revolution with colleagues from other companies, the question I get asked most often is whether the Rust team was slower than a C# team. It’s a very common and reasonable concern as Rust is a lower-level language and you have to do manually what higher-level languages like C# do for you automatically. But we did not experience any significant drop in developers’ performance. It is even more surprising taking into account that modern C# is a pretty damn good language.
While I do have my issues with C#, right now C# is arguably one of the best programming languages for complex backend software: it’s reasonably fast, cross-platform, and it has clear syntax and modern features. I don’t even see much competition: using Python would be slow in production and hard to maintain due to poor type system, C/C++ would decrease development speed and regularly surprise you with memory leaks (even the best of us are prone to it), Go tends to be a poor choice outside its comfort zone (microservices), etc… The only language I can probably make a better case for is Kotlin but only if you’re really into the Java ecosystem.
C# definitely does a lot of things right and, it raises a question why after shifting to a lower-level language, the development process did not slow down. Here is a detailed article explaining why it could be the case. I would also add that when you’re working on truly complex software, it could easily take up to a year for an engineer to be comfortable with the codebase. So what matters a lot is talent retention which is mostly based on engineer satisfaction, and that’s another area where Rust shines.
Conclusion
Instead of getting too deep in the technical details, I wanted to share some of the less discussed and probably less obvious aspects of shifting to Rust both from the perspective of an engineer and the whole company.
Overall, for us, migration to Rust was a beyond positive experience: everything got together in an absolutely perfect way. While Rust clearly was not the only reason behind all those advances, it was definitely a key element of it.
I hope the content of this article did not offend anyone who prefers other languages. While we figured out what worked for us, there’s no one right way to write software: the devil is in the details and there’s a place for all kinds of languages.