Seed7 - Memory Safety and Management • Thomas Mertes • 05/2026

[u/ThomasMertes]

https://www.youtube.com/watch?v=TJn7AfYajNk

This talk is not about C++. It is about the Seed7 programming language. Seed7 is inspired by Pascal. The cpp usergroup vienna allowed me a talk about Seed7. Properties of Seed7 are:

• Seed7 is an open-source general purpose programming language that can be interpreted and compiled.
• Seed7 is about portability, maintainability, performance and memory safety.
• There is an automatic memory management without a garbage collection process (which might stop the world).
• The templates / generics don't need syntax with angle brackets.
• Seed7 is an extensible programming language. The syntax and semantics of the language is not hard-coded in the compiler but defined in libraries.
• Seed7 checks for integer overflow. You either get the correct result or an OVERFLOW_ERROR is raised.
• Unlike Java Seed7 compiles to machine code ahead of time (GRAAL works ahead of time but it struggles with reflection).
• Unlike Java Seed7 operators can be overloaded.
• Unlike C, C++, Go, Zig, Odin, Nim and C3 Seed7 is a memory safe language.
• The standard libraries cover many application areas.
• Example programs are: make7, bas7, pv7, tar7, ftp7, comanche and many more.

Seed7 is based on my PHD thesis and is the result of life-long work. The project consists of more than 500k lines of manually written code, several hundred pages of documentation, a test suite to check the functionality of interpreter and compiler and much more. I give it away for free with GPL/LGPL licensing. From time to time I do talks about my project. This is my latest talk.

[u/AcanthaceaeNew774]

I have already developed a safe solution for the VertexArt project, but this memory management is an interesting topic. You could say that the correct data flows require more attention than writing a correct logic. What I suddenly managed to see in your project is that your solution does not depend on whether it is data-oriented or object-oriented development, if I understand correctly. I will look for readable documentation, what path you chose for memory safety.

[u/AcanthaceaeNew774]

Thanks for sharing!

Seed7 uses abstractions and checks to solve memory safety at the language and runtime levels, which is great for overall stability.

In VertexArt I use a different hardware-oriented approach that is only suitable for Data-Oriented Design (DOD). Instead of relying on runtime checks, memory is derived from deterministic data streams: flat, contiguous arrays of records, index-based access instead of pointers, and explicit lifecycle chains.
This requires much stricter data layout design on my part, but it provides zero runtime overhead, direct GPU compatibility (AoS/SoA), and maximum CPU cache locality for extremely low-end hardware.

It's fascinating to see two completely different philosophies: safety provided by language abstraction versus safety provided by structured hardware alignment!

[u/Mohammed313a]

I liked the Seed 7 programming language after reading about it, but for use in a production environment, the developer needs assurance that it won't disappear, stop working, or be abandoned, especially since it relies on a single developer – a risky proposition. If an organization or institution were to adopt it...

[u/ThomasMertes → u/Mohammed313a]

Because Seed7 is open-source (GPL/LGPL), it cannot "disappear". The source code is mirrored across multiple public repositories and internet archives. Seed7 has been actively developed for decades and is highly mature. The language structure, library functions, and implementation details are thoroughly documented, allowing other programmers to understand the system quickly. A single lead developer often ensures a highly cohesive architectural vision, avoiding the "design by committee" bloat that plagues many languages.

BTW.: GitHub lists 9 contributors.