C++ on TrustLang

Why C++ or Rust can never replace Python

Tue, 28 Jul 2026 00:00:00 +0000

Articles analyzing the phenomenon of Python periodically appear on Habr — how one of the slowest programming languages became the king of neural networks, and the answer is always the same: thanks to a simple syntax and a developed ecosystem. But the ecosystem of C++ is significantly larger and richer, so it is not the ecosystem, and only the syntax remains. And if the problem really is the syntax, then there should also be an answer to another question: why did C++ not become the basis for research in this (or any other) area?

The Achilles' heel of C++ and the future r̶e̶ evolution

Fri, 10 Apr 2026 00:00:00 +0000

Recently I published an opinion about a fundamental economic model of software development that does not contribute (and objectively should not contribute) to a mass transition from C/C++ to “safe” programming languages The economics of code safety, or why Rust is not needed.

But to remain honest with the readers, I decided to also publish a counter-argument article describing the other side of the coin, that is, why C++ will still be replaced sooner or later, and at the same time to try to analyze what the new programming language that will inevitably replace C++ will look like.

The economics of code safety, or why Rust is not needed

Sat, 04 Apr 2026 00:00:00 +0000

I read the article Parallelism with shared state in Rust and noticed that its general meaning can be expressed by the well-known phrase: “do what must be done, and what must not be done — do not do”. In other words, it is exactly the same advice that can be given to a developer of any other programming language, for example C++.

And I decided not to continue the discussion in the comments, but to express my opinion as a short article describing a fundamental economic model of software development that does not contribute (and objectively should not contribute) to a mass transition from C/C++ to “safe” alternatives. Because, due to the peculiarities of cost distribution, the software developer has no economic motivation for the complete elimination of errors, and as a consequence — for the transition to the use of “safe” programming languages.

C++ safety and Buridan's mice in IT

Thu, 02 Apr 2026 00:00:00 +0000

In IT there is a strange form of “informational inertia”: when a phrase once landed well on reality, became a quote, turned into a marker of “one of us” — and then continued to live on its own. Reality moved on, practices changed, tools became different, the economics of development flipped over, but the cliché of the formulation remained. And it is repeated especially willingly by those who need to write quickly and convincingly, but have no time (or competence) to sort out the technical details.

Generic programming in different languages

Tue, 24 Mar 2026 00:00:00 +0000

Generic programming is a paradigm that allows describing algorithms and data structures in abstraction from concrete types. Despite the single concept, each language implements it in its own way: through templates, parametric polymorphism, type erasure or duck typing. This article provides a detailed analysis of the mechanisms of generic programming in eight languages - C++, Java, C#, Python, Rust, Haskell, TypeScript, Julia - with an assessment of the strengths and weaknesses of each approach and a comparative summary.

Getting rid of Segmentation fault errors due to stack overflow in C++

Wed, 07 Jan 2026 00:00:00 +0000

January 7 at 14:53 2026

Developing the idea of a trusted programming language, I came to the conclusion that, through restrictions of the syntax and the creation of corresponding checks in the static code analyzer, it is possible to protect against practically all technical errors except two — the control of dynamically allocated memory and stack overflow.

Moreover, while solutions exist for reference counting at runtime, stack overflow control cannot be done not only during the analysis of the source text of the program, but it is practically impossible even during the execution of the application! After all, a stack overflow error is always fatal, since there is no way to catch and handle this error from inside the running program in order to then continue its execution as if nothing had happened.