Memory-Safety on TrustLang

Memory management and shared access

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

No single memory management approach is the best or universal: different approaches win under different conditions:

Manual memory management can do anything, except one thing — guarantee the absence of errors.
Ownership and borrowing analysis at compile time makes it possible to prove the correctness of code without additional runtime checks, but some scenarios and algorithms cannot be proven statically at compile time.
Counting strong and weak references at runtime is convenient for shared ownership, but has a non-zero cost and does not protect against cyclic and cross dependencies.
Garbage collection simplifies working with complex cyclic structures, but has the most expensive overhead and non-deterministic execution.
None of the listed memory management approaches includes the issues of inter-thread memory access synchronization.

Therefore, choosing only one memory management approach in a programming language means deliberately limiting its capabilities and adding unnecessary overhead. For these reasons, the memory management concept of TrustLang allows extending the implementation of the memory management model with minimal impact on the language syntax and is defined by the requirements (guarantees) for working with memory.

Software safety

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

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.

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.

A possible solution to the problem of references in programming languages

Tue, 23 Apr 2024 00:00:00 +0000

Any programmer is familiar with the notion of a “reference”. This term usually means a small object whose main task is to provide access to another object physically located elsewhere. Because of this, references are convenient to use, they are easily copied, and with their help it is very easy to gain access to the object that the reference refers to, and one can gain access to the same data from different places in the program.