>This looks 100% like personal resistance, rather than technical.
>there's no proof that it "was never going to work"
Did you really just skim the post you replied to? It said:
>Not without ample support within the existing developer base.
Should be clear enough, but I will expand: This is about pre-existing Linux developers and maintainers not willing to commit to the new language, and thus it has nothing to do with anything technical at all.
It won't work because it absolutely requires ample support within Linux's developer base to succeed, and such support is not there.
Nearly nobody, even within the core (which support is needed the most!), is willing to put any effort into this.
I will re-state what I already said:
The best and kindest path Linus could have taken would have been to firmly reject the new language from the start.
As that is no longer possible, the second best still is: To declare the experiment a failure and conclusively remove the new language from the kernel.
The resources freed in Linux's and Rust's communities could then be put to better use, and after a while everybody would be a little less miserable.
So far, the only actual support that has been required is to not actively sabotage it. That’s not a high bar.
There does seem to be very substantial interest in RfL in the kernel, with the exception of a few maintainers generating a lot of personal friction.
Frankly, it’s exactly the kind of behavior you would be very worried to see from key people maintaining the most important operating system on the planet.
My understanding is that part of the reason Linus approved the project is that the current state of Linux is unsustainable. I agree with him. Linux will evolve, or die. Gradually moving on from C will probably be part of that journey, sooner or later.
>There does seem to be very substantial interest in RfL in the kernel
Citation needed.
>the current state of Linux is unsustainable.
I agree. And the issues are fundamental, to do with lack of structure. Doing anything in Linux is harder (in man hours) than doing it on a well-structured system. By orders of magnitude.
But I do not see how to "evolve" a project that big (MLoCs) from chaos towards structure.
Rather, I feel that a rewrite is a much better path.
It could be a fundamentally much better design. A microkernel, multiserver design.
Such efforts include:
seL4 (a formally verified microkernel that also happens to be the fastest available) and multiserver efforts on top of it such as LionsOS or Genode.
Redox (a multiserver OS with its own microkernel, written in Rust).
There have been no serious technical obstacles, and no actual incidents where maintenance has become harder because of it.
This looks 100% like personal resistance, rather than technical.