Hi David,

Just as I replied before, here follow my thoughts on the topic.

On Sun, 22 Mar 2026 14:33:45 +0100
David Hoppenbrouwers <david@???> wrote:

> Memory safety *is* a property of the language, especially if you need
> the language to run on bare-metal without a runtime.

Memory-safety is a property of the program, not the language. The
language can be designed to help compilers make programs with that
property.

It is obvious that there are memory-safe programs in C compiled with
GCC or LLVM. Just as a rule, every compiled Rust program, can be
disassembled and translated to C, therefore the compiler would likely
produce a memory-safe C program.

Using a restrictive language to gain some property is one way to do it.
For instance, using non-Turing-complete language in BPF or using
restrictive C-like language that you can prove a property in compiled
program in eBPF.


> > You may want to check Fil-C[1], which is a memory-safe
> > C and C++ compiler. It has overhead though.
>
> Unlike Rust, Fil-C requires recompiling every single library. It also
> requires a runtime, making it unsuitable for bare-metal development.
I did not argue about this. I mentioned that there is an overhead. My
argument is about calling a language "safe".

> And from what I heard, it has a race condition in its capability
> model which will _not_ be addressed because it would add even more
> overhead.
> https://gist.github.com/unixpickle/4eaae977d79c3b9eeda45d5baf52859f
Therefore, if that problem is addressed, then the *compiler*, would produce
even more memory-safe programs than the current C/C++ compiler or the
Rust compiler with "pointer-twiddling unsafe Rust"[1].

Kind regards,
Marin

References:
---
1. https://graydon2.dreamwidth.org/320265.html