Before You Lecture Us About C++… Try the Hell of Designing a Language!

When I Went from Using a Language to Building One

I am currently developing my own programming language. In the initial benchmarks I have conducted, it has achieved performance close to C, C++, and Rust in the cases I tested. I am not presenting this as a declaration of victory across the board. These are preliminary results from specific tests, not a definitive judgment on an entire language.

But behind those results lies an experience that never appears in the charts.

With every step forward in the language’s design, I return to the benchmarks. I add a feature and ask: What has this done to performance? I simplify a programming pattern and wonder: Where is the cost hiding? I strengthen a protection mechanism and then examine the result: Have I achieved safety through better design, or have I introduced an overhead that every program will have to bear?

There is an enormous difference between saying, “Add this feature,” and being the person responsible for making it work without undermining the rest of the design.

From the user’s chair, a feature looks like a line on a wish list. From the language designer’s chair, it can become a battle with the entire language.

Safety Is Not a Switch… and Performance Is Not Wishful Thinking

When discussing memory safety, it is not enough to say, “Prevent errors.” You have to ask: Which errors? Through what mechanism? What can be proven at compile time? What requires a runtime check? Which programming patterns will you allow, and which will you restrict?

And let us be precise: It is not true that every improvement in safety means a reduction in execution speed. Rust’s ownership system relies on rules checked by the compiler, and those checks do not themselves become a runtime burden on the program. That is an engineering achievement deserving of respect. (The Rust Programming Language, “What Is Ownership?”)

But execution speed is not the only factor in the design equation. There is also how a solution can be expressed, and the limits of what the compiler can prove. Rust’s own documentation explains that static analysis is inherently conservative: it may reject a correct program when it lacks enough information to establish its safety. (The Rust Programming Language, “Unsafe Rust”)

So this is not the simplistic spectacle some people imagine: one team cares about safety, while the other insists on putting users at risk!

The real question is: How do we distribute the responsibility for proving safety among the language, the compiler, the tools, and the programmer? What do we gain or give up with each choice?

C++ Is Not Devoid of Safety Tools

Portraying C++ as a language that offers programmers nothing but raw pointers and memory they must manually chase down is a distorted picture. It provides automatic resource management through RAII, smart pointers that express ownership, and clear guidelines for reducing hazardous manual management. These are not obscure tricks on the sidelines; they are central to modern C++ programming guidelines. (C++ Core Guidelines)

But a serious defense of C++ does not require exaggeration in the opposite direction.

The existence of these tools does not mean that every C++ program is safe, nor that expertise makes a programmer immune to mistakes . Even the use of smart pointers does not, by itself, prevent every dangling reference or lifetime-management error. That is precisely why the guidelines address these risks explicitly. (C++ Core Guidelines)

Discipline matters, but it is not a magic spell. Tools matter, but their mere existence does not constitute a comprehensive guarantee.

Nevertheless, there is a substantial difference between saying, “This language does not enforce comprehensive safety guarantees,” and saying, “This language knows nothing about safety.”

The first is a technical observation worth discussing. The second is a slogan that erases the details instead of understanding them.

Freedom Is Not Another Word for Negligence

Among C++’s central design principles are that you should not pay for features you do not use, and that well-designed abstractions should be able to achieve efficiency comparable to what you would write manually at a lower level. This is a design principle—not a promise that every C++ program will automatically be the fastest. (Standard C++ Foundation FAQ, “The Big Picture”)

That is why I reject reducing its philosophy to: “Speed—even at the expense of everyone’s safety.”

The idea, as I understand it, is that you should remain able to know what is happening, control what you pay for, and choose the mechanism appropriate to your problem.

But the freedom I defend is not the freedom to produce errors and then excuse them in the name of performance. A program that corrupts memory does not become an achievement merely because it finishes quickly!

The goal is not to justify risk, but to reduce it without forcing every engineering solution into a single mandatory policy.

Anyone has the right to question whether C++ succeeds in achieving this balance or fails in some aspect of it. But treating the balancing act itself as stupidity is not scientific rigor. It is ignoring the problem.

Rust Deserves Respect… Not to Be Used as a Club

I do not need to diminish Rust to defend C++. Nor do I consider a strict compiler a flaw in itself. On the contrary, I see genuine value in preventing an error before it reaches execution.

Even the existence of unsafe in Rust is not a scandal that demolishes its premise. It establishes an explicit boundary for operations whose safety the compiler cannot guarantee on its own. Within that boundary, specific obligations fall to the programmer, who remains responsible for building safe interfaces around those operations. (The Rust Programming Language, “Unsafe Rust”)

The problem is not Rust’s achievement. The problem is turning that achievement into a tribunal in which every other philosophy is reduced to an accusation.

You have every right to prefer its guarantees. You have every right to consider it the best fit for your project. But your preference does not exempt you from understanding what you criticize, just as my affection for C++ does not exempt me from acknowledging its weaknesses.

A language is not a tribe, and choosing a tool is not a pledge of allegiance.

Criticize All You Like… But Bring Engineering to the Table

My experience building a language has not led me to believe that C++’s designers are infallible. It has helped me understand why good answers are not always short, and why a decision does not become better merely because it is easier to sell.

I have gained a greater respect for the difficulty of reconciling competing demands, and a greater suspicion of any statement that begins with, “All they have to do is…”

No. Not everything is that simple.

A better solution may be possible, and we should search for it. An old decision may need revisiting, and we should revisit it. But progress does not begin by assuming that those who came before us understood nothing—and that we have resolved their dilemma in a comment!

I am not asking for criticism to be silenced. I am asking it to rise to the level of the thing it criticizes: Identify the flaw, explain the guarantee you require, propose the alternative, and make its cost clear.

As for declaring victory over C++ with the words “It is unsafe,” while ignoring the rest of the equation—that is not a technical victory.

C++ does not need to be worshipped… but it deserves criticism more intelligent than slogans. And anyone who thinks combining power, safety, freedom, and performance is straightforward should try building a language. They will discover that the hardest line is not the one a programmer writes, but the decision that determines what they are allowed to write.