I think both things can be true. The worst of the LKML are crybabies. The worst of Rustaceans are zealots. The worst of any community are usually a vocal minority. Rust for Linux can continue on their mission, and that’s noble. But conflict is to be expected between the babies and zealots, naturally. RFL is not mutually exclusive with a Rust Linux clone. Drew’s proposal seems like a perfectly reasonable parallel project to the RFL project.
> But conflict is to be expected between the babies and zealots, naturally.
Let's note: that's not what happened here. A baby didn't meet a zealot. Here, a baby just lost it.
> Drew’s proposal seems like a perfectly reasonable parallel project to the RFL project.
I agree a Linux compatible Rust OS is perfectly reasonable. I'm not sure it's a reasonable alternative. One contributor leaves because of technical nontechnical nonsense, so let's call the whole thing off? Rust was being included for a technical reason. Is this technical reason less true? Can Linux do without memory safety?
Throughout your posts, I notice a recurrent theme of false equivalence between "rust" and "memory safety".
Rust is merely a tool; a language that makes memory safety easier. It is not required for memory safety, nor does it, by itself, guarantee memory safety.
This is particularly true in supervisor mode, with hardware other than the CPU itself within reach.
> Throughout your posts, I notice a recurrent theme of false equivalence between "rust" and "memory safety".
I'm glad you were able to reason through it.
> Rust is merely a tool; a language that makes memory safety easier.
I suppose, if I overstated the effect Rust might have on memory safety, you risk understating it here.
> It is not required for memory safety, nor does it, by itself, guarantee memory safety.
No, but it does an incredible job?
This reminds me of a post, on this site, I saw which said something to the effect of "ZFS is only great because it is the only filesystem in its domain" which is ridiculous on it's face, but I think even more ridiculous as you dig a little deeper.
When someone who keeps shooting themselves in the foot says, "That safety doesn't prevent all the ways you can kill yourself". Sometimes you want to scream to that fool who manages to continue to avoid using the safety: "What more do you want?"
> This is particularly true in supervisor mode, with hardware other than the CPU itself within reach.
Of course, I'd agree to some extent, but I think your framing is again perhaps overly narrow. Rust is a really good tool. It's such a good tool I hear they are trying to write drivers with it in the Linux kernel.
>It's such a good tool I hear they are trying to write drivers with it in the Linux kernel.
And it's going to be a nightmare, because Linux famously makes changes every now and again which require maintainers monkeying all over code they do not know well to change references to functions and structures.
This is hard enough with just C, it is untenable with Rust.
Let's be honest. Linux isn't even that good. Is it worth the pain? The rust devs could get much more work done and without conflict if they worked on their own system, such as Maestro[0] (unix-like, AGPL but MIT if you go back just a few non-code commits) or Redox[1] (microkernel and multiserver proper, MIT).
