On Mon, Sep 1, 2025 at 4:22 PM David Niklas via Dng <dng@???>
wrote:

> Why not use Python, Ruby, Pascal, SH, etc., in the Linux kernel if you
> want memory safety?
>

I'm afraid you are missing really critical points about what makes a
language suitable for kernel development.
The most important is the ability to deal directly and efficiently with
memory-mapped hardware. You need to catch
up upon this before seriously joining this sort of discussion.

Pascal has been the #1 recommended replacement for C/C++ code for years
> before rust showed up?


Perhaps Oberon, the last in the Wirthian family of languages, since he did
write an OS in it.


> We've had options to help with C code guys!


This is another catch-up point for you. We've had various approaches to
memory safety,
and I count my Electric Fence as the very first, although only suitable for
debugging. But they
are band-aids to a 1970's language that is close to being a
hardware-independent assembly
language, rather than something with support for what we have learned about
programming in
55 years. C++ adds object orientation and generics, but not as nicely as
later languages, and
does _nothing_ about safety, while that is Rust's major concern.

C is simply not capable of enforcing memory safety, re-entrancy, and object
lifetimes without
adding so much to the language that it would become Rust, or at least Zig.
More knowledge of these
things is necessary before you should really have an opinion about the
appropriate languages for
kernel programming.

In fact, Linus Torvalds himself said he did not want object oriented C++
> code in the Linux Kernel.


The reasons were that C++ did not add much value to kernel programming, and
many of its library
constructs were better suited to application programming than
embedded, real-time, or kernel because
they made frequent and essentially unbounded use of dynamically-allocated
memory.
In contrast, Rust is a systems programming language and has had a lot of
attention to running small,
embedded, and bare-metal environments as _well_ as higher-level
applications.

--
Bruce Perens K6BP