Alexander Zaitsev - My Rust Story
Rust turns 10 in 2025, making it a great time to celebrate the language and its community. #MyRustStory series features insights from community leaders shaping the Rust ecosystem.
Want to meet them in person? Attend Rustikon, the first Rust conference in Poland!
It's time for our next expert - Alexander Zaitsev, Co-Founder and CTO of Cytopus.
How did you first get introduced to Rust, and what were your initial thoughts about it?
I first encountered Rust around 2016, when I was still a student at the university. My first impression was, "It's cool, but there's too much instability and fast-changing stuff in the ecosystem - I'm not ready to get involved with it seriously. So, I'd rather stick with C++, my primary programming language at the time, which earned me a salary." After that, I put Rust aside for a few years, occasionally looking at it and evaluating its development path, but nothing more.
Can you share a moment when you realized, “Wow, Rust is amazing”? What features or capabilities of Rust made you feel that way?
It was the moment when I rewrote one of my pet projects from C++ to Rust. I was amazed not so much by the segfault-free programming process but by the convenience of tooling in the Rust ecosystem. It was simply an incredible experience after such a disjointed and terrible C++ ecosystem. Imagine, for a "native" programming language, it turns out that you can connect dependencies in a couple of seconds, and they work right away! Instead of adventures with different dependency managers in C++, fixing their nuances, and reading the documentation for building dependencies for each project separately, all this is very tiring in practice. Rust allows you to reuse other people's developments quickly and painlessly in those places where you need them. And all of that, you still get a C++-like performance level for your applications - it's just wonderful!
How has Rust influenced the way you approach solving programming challenges?
It depends on the definition of "programming challenge" :) If we are talking about various kinds of sports programming contests or things like Advent of Code, then I do not do such things - there are things much more interesting to me. For solving my own problems, I like Rust because it does not create almost any challenges for me - I struggle most of the time with my problem, not with the problems of the language and / or its ecosystem.
If you could add a new feature to Rust, what would it be, and how do you think it would benefit developers?
I would like to see an analog of “comptime” from Zig in Rust. It seems to me that this feature would significantly lower the entry-level into compile-time programming in Rust. Now, we have macros, which many in the community are unhappy with, and they have good arguments for their dissatisfaction. In turn, more developed compile-time programming can be a powerful basis for static reflection in the language, and this functionality has many interesting applications - for example, efficiently writing serializers/deserializers in an understandable Rust way, instead of scary macros way.
I understand that language designers may find integrating this feature into Rust challenging and that it may conflict with existing functionality in the language. But I would be interested to see it, at least as an experiment.
What’s your favorite programming meme?
Every time I hear someone constantly talking about AI and only AI without understanding the technology, this plays in my head. And, of course, using the “blazing fast” in a sarcastic way ;)
What tools and libraries do you rely on when working as a software developer?
Well, I don't use Rust as a “software developer” - my current role is a bit different, so it influences the answer a bit :) However, my Rust projects usually include the following libraries:
- Tokio (where would we be without it),
- Clap,
- Serde,
- Anyhow,
- Axum.
Regarding tools - I don’t use much beyond the standard Cargo tool, but for my “Awesome PGO” project, I extensively used cargo-pgo.
Besides Rust-specific tools, I frequently use:
- ripgrep for working with logs,
- Docker for containers,
- Linux perf for profiling.
Tell us about a time when Rust made a significant difference in a real-world project.
I would like to say more about the impact of Rust on the industry as a whole, rather than on any specific project. Coming from the C++ world and working in cybersecurity, I am very pleased with how Rust has raised the issue of memory safety (that is a vital part of the bigger security field) to a whole new level in the industry. Before Rust, we generally accepted memory bugs in C and C++ as something to be taken for granted, as a necessary sacrifice to the Gods of Performance. We understood this was bad but somehow lived with it, inventing many utilities to partially mitigate this problem: various static analyzers, sanitizers, etc. Rust showed the industry that it is possible to have a programming language suitable for industrial use that automatically closes, if not all, then the vast majority of such problems, and in a very convenient way for the programmer. This in turn pushed the community to use this advantage and use it to implement new, more secure versions of applications. It also raised the memory safety debate to a whole new level for C++ itself. Me as a person, and we as a cybersecurity company, are very pleased with this effect. I think over time we'll see the real effects of this paradigm shift in huge projects like the Linux kernel. It won't be fast, but it will happen eventually.
How has the Rust community shaped your programming journey? Are there any standout interactions or stories of support you'd like to share?
My interaction with the Rust community has probably almost always been positive - it's hard to single out anything “the best” in particular. I want to thank the Rust compiler development team for their titanic work to make working with the Rust compiler such a pleasure from a developer's point of view. As part of my "Awesome PGO" project, I'd like to thank Jakub "Kobzol" Beranek for his work on speeding up the Rustc compiler, for developing the "cargo-pgo" utility, and simply for answering my questions - it was always a pleasure to talk to him.
Did you experience any funny or embarrassing moments while learning Rust?
I have a funny story about writing multithreaded code when I was polishing my Rust skills.
For one of my pet projects, I needed to use the AWS SDK for their service, AWS Gamelift. Since there was no SDK in Rust, and I did not want to develop Rust bindings to their C++ SDK, I decided to quickly rewrite the SDK in Rust. Fortunately, the SDK itself was open source and quite small, so the matter did not seem so difficult.
Having completed the work quite quickly, I published the SDK on GitHub. However, after some time, a person came to me on GitHub with a bug report - it turned out that I could create a deadlock inside the SDK! Yes, I know perfectly that Rust does not protect against such errors, but I laughed to myself about "fearless concurrency" - after all, even with Rust, you should “fear” a little bit :)
What advice would you give to someone just starting out with Rust?
Whether you are starting your programming journey from scratch or are an experienced programmer who has decided to learn Rust, do not be afraid to contribute to open-source projects!
I often see similar questions on the Rust subreddit, and every time I want to answer - "Look at what Rust projects you are using right now and try to improve them!". If you don’t use any - give it a try! It only seems so tricky. In fact, when you start with serious intentions, you can very quickly get involved in this. A number of projects have labels on issues like "good-first-issue" - pay attention to them first. If there are none, then never hesitate to contact the authors of the project with the question, "I am new to Rust, I am using your project - I would like to help improve it. Please tell me where to start. Thank you!" And I guarantee you, almost always you will be able to get some advice on where to start. At first, these will likely be simple tasks: somewhere you can fix tests, somewhere very simple bugs - no big deal, this is also important! But by completing such tasks, you will get acquainted with the project infrastructure, its approaches to development, and the accepted development culture, and you will see what the Rust code looks like in an actual project. After that, you can take on increasingly complex (and, therefore, usually more interesting) tasks. And working on a project that you regularly use will give you additional motivation. It is very nice to realize that your feature is useful not only to you but also to other people around the world. As an additional benefit, it could be a nice addition to your portfolio, this will help you find a job. I got my first job as an engineer specifically for my GitHub profile.
Do not expect every open source project to give you a personal mentor - very few projects can afford such a luxury. You will have to explore many things yourself, and this is absolutely normal - this is how things work in the industry. If, after all your attempts to figure it out on your own, you have reached a dead end, feel free to contact more knowledgeable colleagues on the project. Seeing your question and how you tried to solve the problem - they will most likely try to help you because they will see your motivation.
I got this advice about 10 years ago from a very good engineer, and it helped me a lot at the beginning of my engineering journey. Now, it's my turn to give this advice to anyone else.
How have you seen Rust evolve over the years, particularly in your area of work?
You know, I like that Rust is getting... boring, regardless of any particular area. Yes, boring. When I first got acquainted with Rust, there were quite a few ready-to-use libraries in the ecosystem, many of which contained fairly basic functionality (the 80/20 principle, you know), the language often received features that were quite important for everyday work, etc. If you are an enthusiast of new technologies, then it is definitely interesting to be in the center of such actively-evolved things. But if you just want to get your job done… Instability is not the best thing to deal with.
Now, the ecosystem has improved a lot. It is pretty rare for me to encounter a situation where I can't find a library in Rust (for my use cases!), and they are generally of pretty good quality - I don't even have to patch them often! The language has a fairly good set of features for almost painless use in many scenarios. This is exactly what I want to see from a good technology for the industry. There are definitely niches where Rust as a technology has yet to make a serious statement - like AAA gamedev, but we are moving towards it.
What do you predict for the future of Rust over the next decade?
I'm not sure if I'm that good at predicting, but here we go.
In the next decade, the share of Rust in the industry will definitely increase, most likely by a significant percentage. I draw this conclusion based on the available materials from both large market players - such as Microsoft and Google - and many publications from smaller companies. Many success stories could be found on the Rust subreddit, and far-far less - about moving back from Rust to something else.
I am definitely sure that in the next decade, Rust will not become a "killer" of any programming language (most often, I see mentions of Rust as a "killer" in the context of C and C++) - please, don’t fall into this trap. Too much code is written in these languages, and this code is still very important for the industry. Manually rewriting it is not economically feasible, and we have not yet invented sufficiently good automated tools. Although research is being conducted in these areas, so far I have not seen good enough results for mass use, even with “magical” LLM-based things.
Is Rust only for systems programming, or do you see it as a valuable technology in other areas as well?
I really don't like the term "system programming" because, in my humble opinion, people still don't have a clear understanding of what it is. Writing operating systems, writing drivers for them, embedded development - I don't know, and I've seen too many disputes about the exact definition (without any final benefit for anyone).
Let's assume that in this case, by “system programming”, we mean "writing OS and drivers". Then I can confidently say that Rust is suitable for other things. I had a great experience using Rust for writing backend services, for writing CLI utilities for all occasions, and for game development (at least when you don’t need to integrate tightly with “serious” game engines like Unreal Engine and Unity). These are just the things I personally had experience with. If you look in the community, I see many more success stories in completely different areas of programming: databases, log solutions, compilers, etc.
More specific cases need to be considered separately, and there are issues such as library availability (which can sometimes be a serious limitation for Rust even with the ability to write bindings), regulatory issues such as the availability of certified compilers (here we have Ferrocene, but it’s not that simple in real life) and a number of other issues come into play. But in general, Rust can be used very well in many areas outside "system programming".
Check other #MyRustStory: