The Linux kernel didn't get written because people on a forum said "we need to write a complete open source reimplementation of the UNIX kernel," but because Torvalds just went ahead and wrote it. Most things in F/OSS work that way.
Hello everybody out there using minix -
I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386(486) AT clones. This has been brewing since april, and is starting to get ready.
https://groups.google.com/forum/#!msg/comp.os.minix/dlNtH7RR...
It would be much easier to submit patches to slowly upgrade the kernel to a memory safe language, but that would require a lot of political savvy to push through, also making it an unlikely path to be taken. Ultimately, you'd have to convince Linus of the merits, and we all know how much he likes complex languages.
For one, Rust is a different language from the other memory-safe languages that have existed in the past, and in fact incorporates a lot of research in programming languages that didn't exist when Ada was designed. But even if that weren't true, one thing that's changed since the past is we now are slowly understanding how difficult it is to write secure software in C, and how important it is to write secure software. When Unix was first designed we (the entire programming community) didn't know about a lot of security issues, and the lack of Internet meant that it was less important to defend against them. It is probably much more worth rewriting our tools in Ada today than it was ten or twenty or thirty years ago.
IMO, because it's harder to break the rules. Sometimes the rules just need to be broken. There was a recent article about someone attempting to interface with OpenGL in Rust a month or so ago, and it discussed how they ended up giving up, since the things they needed to do didn't mesh well with how Rust expected programs to be written. If interfacing with a driver is so hard, how will interfacing with hardware be easier?
Programming for hardware requires a lot of breaking and bending the rules. How can being memory safe help when you're creating memory spaces as most software knows of it?
Performance is King, low memory overhead is Queen. Even rust can't take those thrones away from C. Not yet, at least. Perhaps not ever (I expect that C++ would have done it, were it possible for a language with the complexity of Rust).
> If interfacing with a driver is so hard, how will interfacing with
> hardware be easier?
I'm still a noob at this kind of thing myself, but I recently wrote a (tiny) driver for a memory-mapped device. My first iteration had tons of unsafe code. My second iteration had three lines of unsafe code. My latest iteration has zero unsafe code, though you do need one call to an unsafe function outside of it in order to construct it. (to create a slice from the raw memory location that's mapped.)
That is, of course, pretty much the simplest possible case. But I believe the pattern will hold, over time, as people learn how to do it.
> Even rust can't take those thrones away from C.
So, then, why do you think that "We need to rewrite everything in Rust" isn't doing something productive? I've been a C++ and C developer for a long time and have been waiting for some safer language that lets me do what I've been doing in those languages. Knowing that Rust was a realistic option was what inspired me to learn it and write new things in it. If that happens at scale, that's how we actually get things written in a memory-safe language.