Rust, C++, and the Tradeoffs Behind Safe Low-Level Code: interview with Nikita Lisitsa<br>ResearchProgrammingArtificial IntelligenceInterviewsOther
Rust, C++, and the Tradeoffs Behind Safe Low-Level Code: interview with Nikita Lisitsa
Article by Fedor Logachev<br>June 8th, 2026
11 min read
Telegram
Copy Link
In this post, we interview Nikita Lisitsa about C++, Rust, systems programming, and game development.
We discuss whether C++ is still the default path into systems programming, where Rust fits in, and how both languages may coexist over the next decade. Nikita also shares his perspective on memory safety, language complexity, game engine design, real-time physics simulations, renderer abstractions, and the lessons he learned from shipping Costa Verde.
Rust advertises its “if it compiles – it works” stance and its user-friendly/educational compiler messages. Should we start learning Rust as a first step to C++?
I’d say both languages should be learnt in parallel. Both Rust and C++ have a ton of quirks and idiosyncrasies specific to these languages (borrow checker in Rust, duck-typed templates in C++, etc), and I don’t think they are good prerequisites to each other. However, they share a lot, too (being low-level, RAII/Drop trait, caring about object ownership & lifetimes), which is why I think it’s a good idea to learn both at the same time.
Rust’s compiler and safety guarantees allow “learning by trial and error” in multi-threaded synchronization. Should we use Rust as training wheels while learning parallel programming?
I don’t have a strong opinion on this. Rust forces you to wrap shared data in Arc> or something like that, which does prevent data races, but also hides a lot of underlying complexity, and doesn’t prevent a lot of other problems like deadlocks. C++ has a lot of other stuff you have to care about when writing multi-threaded code. To be honest, something like Java still feels like the cleanest language to learn the basics of parallel programming, and then maybe C++ to learn the more complicated, low-level things. But for writing multi-threaded code, Rust is probably the best.
Generalising those two questions – is C++ still the best language to get into system programming?
I don’t think there is a “best” language for system programming, it really depends on what your goals are. Writing Linux drivers and writing high-load multi-threaded data-processing servers are very different tasks. C, C++, Rust, Go, and a ton of other languages can be great for system programming in a suitable context. C++ is generally a pretty good match, but sometimes the manual memory management and unexpected UB can make it not worth it.
C++ keeps accumulating features — modules, coroutines, reflection, contracts. Do you think the language is becoming too complex to use safely and teachably, or is that complexity justified?
The way I see it, there is a certain programming language spectrum between simplicity and complexity. It’s basically a balance of how much you have to keep in your head vs how much your language does for you, but you still have to keep in your head that the language does it for you. C, for example, is closer to the “simplicity” end of this spectrum, while C++ has always been on the opposite end. I personally love C++ for that: you have to learn a lot about what the language can do, but then it pays off as you use what you’ve learnt to your advantage to write simpler, more expressive code.
The current development of C++ follows that same pattern: more complexity that empowers the programmer. There have always been people who refuse to use most of C++ features, and only use some subset of the language, and it makes sense that from their perspective, the language is becoming worse. I personally think it is justified in the context of using C++ in its fullness.
Do you think C++ is a good choice for agentic development?
Never tried agentic development, so I can’t tell :)
With all this AI stuff going on, shouldn’t memory safety/correctness be the first priority of language design?
Memory correctness is just one type of bugs, and, contrary to the widespread misconception, it isn’t the most common bug we have in C++ or any other language. C++, for instance, has been evolving to make memory safety almost effortless — things like smart pointers and proper usage of RAII cover 95% of all such cases. The tooling has been evolving, too — ASAN, for instance, can find most memory-related bugs automatically. Typically, our bugs are simply errors in the program’s logic, and there’s little you can do in the language itself to prevent those. I’d say the focus should be on something like contract-based programming (or, better, proof-based languages that use dependent types / HoTT / etc), and not some specific type of common bugs like invalid memory access.
In game development/system programming, it is considered a good practice to avoid allocations at all...