Rust: A Disappointing Programming Language

Once I considered myself a Rust critic, but I realized I was simply trying to balance out the enthusiasm surrounding it. Rust often ranks highly in developer surveys and is praised as a favorite language, but many are still waiting for a better alternative to C++. Unfortunately, Rust falls short in several critical areas.

One major issue is its slow compilation speed. Despite improvements over the years, Rust remains significantly slower than C++, and needs to be at least two orders of magnitude faster to be practical. Its complexity is another concern; like C++, Rust’s syntax often feels like navigating a jungle of `Arc>>`, which hampers logical clarity and makes it difficult to see the bigger picture. This shared complexity raises questions about the benefits of switching from C++.

Memory safety, often touted as Rust’s strength, isn’t always reliable. In many cases, crashing is less problematic than malfunctioning—especially in embedded systems where high reliability is crucial. Rust’s frequent crashes compromise its suitability for high-stakes applications. Additionally, its native memory model struggles with intensive mutable shared states, such as GUIs, databases, or low-level hardware interaction. Non-native unsafe code introduces performance issues, further limiting Rust’s usefulness for large-scale, mutable environments.

C++, in its core, is flawed. It’s built on undefined behavior, meaning many operations—even simple array accesses—can lead to unpredictable results. The language’s design allows implicit conversions, object slicing, and error-prone features like macros and slow build processes. These issues persist, fueled by legacy C paradigms, and make C++ inherently unsafe and complex.

How does Rust attempt to address these C++ shortcomings? Not effectively. Slow compilation is baked into Rust’s design by necessity. Its reliance on heavy generics, monomorphization, and borrow checking makes compilation sluggish by intent, not accident. Efforts to optimize this, like the MIR project, have yet to deliver significant speed improvements. Rust’s compilation model resembles that of Haskell or template-heavy C++, where code complexity and compile time are deeply intertwined.

In summary, Rust promises safety and modernity but often delivers slow performance, high complexity, and instability. Its inability to match C++’s performance and safety reliability limits its potential as a universal solution.

FAQs about Rust:

Q: Why is Rust’s compilation so slow?
A: Rust’s compile speed is inherently tied to its heavy use of generics and borrow checking, which require extensive code analysis and monomorphization, making the process slow by design.

Q: Can Rust replace C++ effectively?
A: Currently, Rust struggles with performance and stability issues, particularly for applications with heavy mutable states or embedded systems, limiting its ability to fully replace C++.

Q: Is Rust safer than C++?
A: Rust aims to prevent many errors through its safety features, but it is not infallible. Crashes and bugs still occur, especially in unsafe code or complex systems.

Q: What are the main drawbacks of Rust?
A: Slow compile times, complexity, frequent crashes, and limitations in handling large mutable shared states are the key drawbacks of Rust today.