An interview with Nikita Lisitsa, a systems and game developer, covering the tradeoffs between Rust and C++ for systems and game programming. Topics include whether to learn Rust before C++, C++ complexity and its growing feature set, memory safety debates, game engine design philosophy, renderer abstraction strategies, real-time physics simulation tradeoffs, and how Rust and C++ might coexist over the next decade. Nikita argues that memory bugs are often overstated as a problem, that C++ complexity is justified for those who use the language fully, and that Rust's adoption in game development is slowed more by ecosystem inertia than technical limitations.
Table of contents
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++?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?Generalising those two questions – is C++ still the best language to get into system programming?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?Do you think C++ is a good choice for agentic development?With all this AI stuff going on, shouldn’t memory safety/correctness be the first priority of language design?In game development/system programming, it is considered a good practice to avoid allocations at all costs. Did Rust people get it all wrong with all the fuzz around ownership?C++ is still the language of choice for game engine development. What does Rust miss, and will it ever be able to compete with C++?Your engine seems to provide low-level graphics/platform/audio/utility infrastructure, while you often reimplement the project-specific renderer per game. Where do you draw the boundary between “engine feature” and “game-specific system,” and can you give an example of a system you first put into the engine but later decided should live in the game?In your soft-body spaceship work and water-over-terrain simulation, you repeatedly choose simplified models that preserve the gameplay-relevant behavior while avoiding full physical realism. How do you decide which invariants must be preserved, such as stability, mass conservation, energy behavior, or locality, and which physical inaccuracies are acceptable for a game?You have used OpenGL 3.3, ported toward WebGPU, built WebGPU demos/raytracing, and used WebGPU compute for browser simulations. If you were designing your renderer backend abstraction today, what would you expose as stable engine-level concepts, and what would you avoid abstracting because WebGPU, OpenGL, and future APIs differ too much?Costa Verde was your first commercial release, and your projects show many jam games and technical prototypes. Looking back, which technical bets paid off when shipping Costa Verde, and which engine or design choices slowed you down the most? How would those lessons change your current village-building game’s architecture, production scope, and tool priorities?The 3-year release cycle — is it the right cadence? Too fast, too slow, or does the cadence even matter given how long adoption takes?How do you see C++ and Rust coexisting over the next decade? Competition, gradual replacement in some domains, or peaceful coexistence?The US government and NSA have recommended moving away from C/C++ toward memory-safe languages. Does that concern you, and how do you think the C++ community should respond?5 Impressions