Comparison on TrustLang

Language comparison

Mon, 01 Jan 0001 00:00:00 +0000

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.

What is the "ideal" goal of the development of programming languages?

Wed, 07 Apr 2021 00:00:00 +0000

Information about the release of a new version of one or another programming language appears with constant regularity. And with each new version its capabilities expand, new syntactic constructs or other improvements are added.

And this very much resembles the development of technology, as in any other field of engineering. When, with each successive stage, the creations being made are perfected. Faster, higher, stronger … and at the same time significantly more complex.