Brian Kernighan, "Only Third to Dennis Richie and Ken Thompson" (UNIX), Agreed With Someone Who Said Rust Was Just Hype, Should Not Replace C
Brian Kernighan, a Canadian, knows a thing or two about programming and programming languages. He has seen them all (not literally) and can assess, compare, etc.
What he said about Rust matters. Some people document this. This recently become a debated topic.
Earlier this month Bruce Perens also wrote about Rust: (responding to someone who had brought up the topic in dyne.org)
Hi Davide,
My understanding was that the community "mrustc" project was a C++ implementation of early Rust that could compile early Rust compiler versions which could be used to bootstrap up to the current Rust toolchain.
Obviously the chicken-and-egg problem is a serious one. The Guix distribution has gotten the farthest, in that they can bootstrap the entire distribution from a 357-byte binary on X86.
I think the best solution would not be to eschew Rust, but to solve its problems to the best of our ability, since Rust represents a lot of advancements in security, re-entrancy, and enforcement of software correctness; over C/C++.
BSD licensing is not really an issue, IMO, but we must be aware that the GPL has aged and we are being even more abused since the advent of AI trained on Open Source. My work on Post Open is meant to address this and other issues and I have a new version of licenses coming soon, merging lawyer reviews.
IMO the best solution might be to bootstrap Rust from a highly-verified build of the compiler targeting Webassembly. This could be made to work in most places. But let's not kid ourselves: many software programs we now depend upon are larger than it is possible for any single human to fully understand. There doesn't seem to be any possibility of solving this problem in the near future.
We also need to be aware that Linux, based on the now 55-year-old Unix paradigm, and Multics before that, is also aged, and that newer kernels are in our future. Redox, a microkernel OS written in Rust, also follows the Unix paradigm but might be a starting point. A truly modern OS would not provide any synchronous I/O primitives, and there are other advancements I could suggest.
Thanks
Bruce
He also wrote:
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
This message by David Niklas also brings up another elephant in the room:
I share your concerns, especially because as Linux moves from a user developed and maintained set of code-bases to a corporate developed and maintained set of code-bases. Rust, as you may recall, is a Mozilla foundation.
I have some ideas for how to solve this problem, but they'll probably have to wait until we solve the problem of corporate controlled firmware that is totally insecure (in the sense that it's never been audited), is able to access the internet without permission, and, in some cases, doesn't allow Linux to boot. Although Intel's IME counts, I'm more concerned about Microsloth's Pluton.
> While I share some of our concerns, I have to say that if you had more > knowledge of computer science, you could not do other than welcome Rust > as a huge advance on C. It is not ideal, but there is a reason that it > has been accepted into the kernel.
I've read this sort of thing over and over again ad infinitum. Why not use Python, Ruby, Pascal, SH, etc., in the Linux kernel if you want memory safety?
No one ever did a review of the various languages available, even rust's author, and demonstrated that rust is, overall, the best replacement for C out there. Did you not know that Pascal has been the #1 recommended replacement for C/C++ code for years before rust showed up? There's a whole C string library out there licensed CC0 and no project ever used it! We've had options to help with C code guys!
In fact, Linus Torvalds himself said he did not want object oriented C++ code in the Linux Kernel. Now we're doing OO with rust! Why not let C++ in then!? We have the STL, so no need to complain about C++ oddities of the past, and we have libgc, so there's little need to complain about memory leaks either.
The reason is all too simple, corporations, including Mozilla foundation, wanted rust code in stuff, so they're pushing for it, and, for whatever reason, Linus has surrendered in this and many other social/corporate matters.
IDK what these big corporations intend, but this whole thing reeks of the old EEE (Embrace, Extend, Extinguish,) campaign. Once they control the major code bases and have displaced most of the freelance devs, we'll be at their mercy. A great way to do this is to increase code complexity, by using tighter SW coupling, systemd, and using more programming languages in projects, rust (and thus requiring rewriting the old, known good, code in the process).
David
Regarding Perens, remember that he objected to a number of things Debian did in recent years, in effect "going with the flow" of Red Hat.
He later wrote: "Can we start moderating this list for a while? This discussion doesn't carry DNG forward, the people pushing it are not cognizant of basic points of computer languages, issues of software licensing, and it's just noise distracting the people who are doing useful work." (Also repeated a similar point)
Censoring some critics would be the sort of thing Rust does a lot in Reddit and GitHub (the sites to which it outsources discussions).
Some people brought up the licence and he said: "Anyone who feels that the GPL is a barrier to their selling their own software, etc. needs to first explain MySQL, Artifex, Alladin Enterprises, and for that matter, Red Hat and its ilk."
"I'm disappointed with Bruce accepting Rust politics," said an associate (who had also claimed "Rust == politics, not code"), "and not mentioning the performance hit that comes with Rust, along with it not actually solving so many memory problems."
"However, his other points about the need for modernization seem to have merit. It's just that old Linux has become such a juggernaut that it'd be *very* hard to bootstrap a new kernel. Microsoft already makes it hard for even Linux to exist. Hurd is finally maturing but odds are low of device driver support. Did Linus ever admit to the superiority of microkernels? I think that's one of the things Bruce is getting at," the associate added.
There's lots more in that discussion thread. Those are GAFAM sceptics who wish to avoid Microsoft/IBM systemd. █
