The Good And Bad Of C++ As A Rust Dev

TL;DR

C++ can feel liberating after Rust because it imposes fewer compile-time constraints, enabling faster iteration but increasing the chance of runtime mistakes.

Briefing Cornell Notes

Briefing

C++ is a “good enough” language for game development—especially when paired with modern C++ features—but its biggest pain points for Rust developers tend to cluster around tooling and developer experience: build systems, dependency management, and the quality of error messages. The conversation starts with a personal detour—learning C++ after working in Rust—then turns into a practical comparison drawn from building a small game with a homemade engine. The core takeaway is that C++ can feel liberating because it lets developers “write code now and fix it later,” yet Rust’s guardrails make many classes of mistakes harder to make in the first place.

After a couple of weeks following an OpenGL tutorial series, the pair finally split responsibilities: the engine side and the gameplay logic side. The sister took over much of the gameplay implementation, while the Rust developer focused on engine features and requests. That division becomes a recurring theme: C++’s flexibility supports fast iteration, but it also enables foot-guns—templates, pointer/reference lifetimes, and build/debug workflows that can slow teams down. Object-oriented design also comes up as a pragmatic tool for games: creating a class hierarchy (game objects, squares, characters) and storing them in a single container to call update/render methods. Even when traits or non-OOP designs are possible, the discussion frames OOP as a common, workable pattern for game code.

The “bad” side of C++ is less about the language’s fundamentals and more about the ecosystem’s friction. Backward compatibility is praised as a technical achievement, but it contributes to complexity and confusion. The lack of a standardized build system is singled out as a major time sink, with CMake described as workable but often clunky—especially when used alongside Visual Studio on Windows and when dealing with “works on my machine” problems. Package management is another recurring complaint: CMake doesn’t provide the same integrated dependency workflow Rust developers get from Cargo, pushing teams toward workarounds like vendoring, global installs, or building dependencies from source. That leads to versioning headaches and inconsistent builds across machines.

Error messages and debugging are where the comparison becomes sharp. Template and linking errors in C++ can balloon into thousands of lines, making it emotionally difficult to diagnose issues—especially when declarations/definitions drift between headers and implementation files. Rust’s diagnostics are portrayed as more immediate and actionable, with IDE/LSP integration that points to missing imports (like trait methods) and highlights mistakes earlier. Even when Rust’s async-related errors can get ugly, the overall message is that Rust tends to provide clearer feedback for common mistakes.

The discussion closes by broadening beyond C++: Bevy’s ECS-based workflow is contrasted with the productivity of a bespoke engine, and the broader “web vs everything else” perception is challenged with GitHub repo statistics. Still, the central thread remains: C++ can deliver a great developer experience for game prototypes and production work, but Rust developers feel the gaps most strongly in build/dependency tooling and in the quality of diagnostics when things go wrong.

Cornell Notes

The discussion compares C++ and Rust through the lens of building a small game and relearning C++ after Rust. C++ is praised for flexibility—developers can move fast, use modern features like unique/shared pointers, and structure game code with familiar patterns such as OOP hierarchies. The main drawbacks for Rust developers are ecosystem friction: CMake’s inconsistent workflow, lack of standardized package management, and “works on my machine” dependency issues. C++ error diagnostics—especially template and linking errors—can be extremely long and hard to interpret, while Rust’s compiler and IDE/LSP feedback tends to be more direct for common mistakes. The practical conclusion: C++ can be productive, but Rust’s guardrails and tooling often make debugging and dependency workflows smoother.

Why does C++ feel “free” to Rust developers, and what trade-off comes with that freedom?

C++ allows developers to write code and defer correctness—there’s less enforced structure than Rust’s borrow checker. That means fewer immediate constraints (no borrow rules blocking patterns), but it also makes it easier to create runtime problems. The transcript highlights this with examples like “difference between references and vector reallocation” and the general idea of “fix it later,” where crashes or weird behavior can happen when assumptions break.

What specific C++ foot-gun shows up in game engines that store references across frames?

Storing references to elements inside a std::vector can break when the vector grows and reallocates. The example described: take a reference to an element (e.g., v[0]), then push another element that triggers reallocation; the underlying memory moves, so the old reference becomes invalid and can crash. Rust makes this harder to do safely, which is why the same class of bug is less likely there.

How does the conversation justify object-oriented design for games even if it’s unpopular?

OOP is framed as a practical fit for game loops and entity behavior. The described approach: define a base GameObject, subclass for specific entities like Square and Character, store them in a single container (a vector of unique game objects), and call update/render polymorphically. Even though traits or non-OOP designs can work, the transcript argues that OOP can be “pleasant” and productive for game code.

What are the biggest ecosystem problems with C++ compared to Rust in this discussion?

The complaints concentrate on build and dependency workflows. CMake is described as necessary but frustrating—especially with Visual Studio integration and recurring bugs that require closing/reopening or even restarting. Package management is also criticized: CMake lacks an integrated standard like Cargo, so developers rely on Conan/vcpkg or vendoring/build-from-source patterns, which can create versioning and “works on my machine” issues.

Why are C++ template and linking errors portrayed as uniquely painful?

Template errors can explode into massive, hard-to-read diagnostics, sometimes thousands of lines, making it difficult to find the real cause. Linking errors are described as emotionally difficult because they often appear late in the build process, after compilation succeeds, and the resulting message can be hard to map back to the original source mistake (like mismatched declarations/definitions). Rust is contrasted as giving more immediate, targeted feedback for similar classes of mistakes.

What’s the practical difference in debugging workflow between Rust and C++ mentioned here?

Rust development is often done with cargo or bazel, and the transcript claims that IDE-style debugging (breakpoints in Visual Studio/VS Code) feels less integrated or less used in Rust workflows. By contrast, C++ is associated with mature debugging experiences in Visual Studio/VS Code, even if the speaker personally relies more on print/printf debugging for Rust projects.

Review Questions

In what scenario does a std::vector invalidate references, and why does that matter for game engines that keep pointers/references across frames?
Which C++ pain points are attributed mainly to language design (e.g., templates) versus ecosystem tooling (e.g., CMake and package management)?
How do Rust’s compiler/IDE diagnostics differ from C++’s template/linker errors according to the discussion, and what kinds of mistakes benefit most from that difference?

Key Points

1
C++ can feel liberating after Rust because it imposes fewer compile-time constraints, enabling faster iteration but increasing the chance of runtime mistakes.
2
Storing references to std::vector elements across operations that may reallocate is a common crash source in game engines.
3
CMake’s lack of standardization and inconsistent developer experience can create “works on my machine” problems, especially when paired with Visual Studio workflows.
4
C++ dependency management often lacks the integrated, predictable workflow Rust developers expect, pushing teams toward vendoring or building dependencies from source.
5
Template and linking errors in C++ can be extremely long and difficult to diagnose, while Rust’s diagnostics and LSP integration are often more direct for common mistakes.
6
Modern C++ smart pointers (unique_ptr/shared_ptr) can mitigate some memory-management risks, and prior Rust experience can help developers use them effectively.
7
A bespoke engine workflow can outperform using a general-purpose engine (like Bevy) when developer experience and iteration speed matter more than peak performance.

Highlights

The most concrete “bad” example is vector reallocation invalidating references—an easy-to-miss bug that Rust’s safety model helps prevent.

CMake and dependency management are treated as the biggest practical friction points, not C++’s core syntax.

C++ template and linking errors can balloon into thousands of lines, while Rust’s diagnostics are described as more targeted and IDE-friendly.

Even with Rust experience, the discussion credits C++’s modern features and tooling maturity for making game prototypes productive quickly.

Topics

C++ vs Rust
Game Development
CMake
Dependency Management
Compiler Errors

Mentioned

OOP
ECS
IDE
LSP
CMake
FPS
AI
ECS