[uecker]

Well, I very much hope that the Linux kernel will never transition to Rust. The language is far too complex for my taste. IMHO Rust people should just build their own kernels and if those are better they can replace Linux just like the C++ microkernels did.

[vsgherzi]

The complaints I have with rust are going to be on the async side. We need memory safety in the kernel, it dosen't have to be majority but having vital parts in rust could be a game changer. The kernel must evolve, all players are moving this way. Swift is being introduced into Darwin, Rust into Windows. Memory safety is not a fad and the only tangible options right now is rust. Swift could be interesting but creates other problems, zig is not 100% safe, and carbon is vapor ware. Could there be something better than rust? Yes. Do I think rust can be annoying at times? Absolutely... But the way I look at it, we don't have another shot.

[uecker]

I think a far better approach to memory safety in C projects is to evolve tools and annotate existing code. It is also not true that everybody moves to Rust and I think the claims about memory safety are overblown (due use of unsafe Rust). In my experience as a observer and contributor of open-source and free software for the last decades, these changes driven by enthusiastic and opinionated small group that try change how existing projects work are very dangerous and often contraproductive both in terms of technical and social risks for the projects. It is far better to start alternative projects that compete on their own merits and if the techniques are truly superior, then those will eventually be competitive. Going into existing projects and changing them according to "opinions" is a really bad idea.

[steveklabnik]

> I think a far better approach to memory safety in C projects is to evolve tools and annotate existing code.

The advantage of Rust is that it already exists. Someone has to do the work to bring that to fruition before it's practically applicable.

> these changes driven by enthusiastic and opinionated small group

In this case, that group includes Linus.

> Going into existing projects and changing them according to "opinions" is a really bad idea.

The Rust for Linux folks already worked on Linux for years. They aren't outsiders.

[vsgherzi]

I agree that memory safety gets over-hyped and is often treated like a silver bullet solution. However, I do believe the problems of memory unsafely to be real and to be a threat (just less than what the popular opinion is). We've tried using static analyzers and C and AI driven detection to limited success, we cannot guarantee correct C code, this is just a hard problem when a project as big and important as the kernel exists.

Rust was an experiment proposed by Linus so I don't really see this as driven by a small group, it should be the standard as that's what Linus wanted to try. It's an experiment that's having social problems.

I think alternative projects are a good idea and some are already being and have been created, but the Goal of this experiment was to help Linux evolve in a direction to keep the kernel competitive and healthy.

I think Rust is a great idea but it might not be the right fit for the kernel socially, which is unfortunate. Maybe the only option forward here is improving C... but that seems like an impossible task without breaking changes. I do hope for the best with the kernel and with the RFL maintianers.

[uecker]

There are definitely people using static analysis to write memory safe C. This is not really practical though, but getting a reasonable level of memory safety is very much possible using tools and good design. People dismiss this because it is not perfect, but this completely fails to take into account that - in practice - Rust is also far from being memory safe due to use of unsafe.

Whether it was proposed by Linus or not, it still driven by a small amount of people. I do not think it was a good idea from Linus to allow it. I understand the arguments he had, but I think it was a mistake. In the past, he kept the C++ programmers out and I always thought this was a wise decision. And the arguments for C++ were not entirely different, except it was not memory safety but object orientation which was "clearly needed" and "the right way" and everything C is old, obsolete, and wrong. By just saying no he kept this discussions away.

[vsgherzi]

Rust is memory safe by every definition. Unsafe is an escape hatch that is only used when safe won’t work and assumptions can be made by the programmer. This is a needed solution and does not take away from rust as a safe language.

To me Linus is the leader so if he wants to try it we should try it. If he wants it gone then it should be removed all the same. Linus did not include rust for something like a programming paradigm it’s for the safety of the kernel and hope to attract more younger contributors.

The kernel will eventually need to evolve and I think this experiments are extremely important to prevent the kernel from turning irrelevant.

[uecker]

Safe Rust is memory safe when used exclusively while unsafe Rust is obviously not memory safe, and a mix might also not be. If you use unsafe blocks carefully in Rust it is still quite memory safe but if you use unsafe blocks carelessly is not very memory safe. My favorite example is the CVE in a matrix transpose function: https://github.com/advisories/GHSA-5gmm-6m36-r7jh A similar error in C would be taken by Rust proponents as clear sign how dangerous C is. Overall, in practice, the safety of Rust is not so clear as proponents claim, except when strictly sticking to the safe part.

I think the experiment is a mistake and the kernel would obviously stay relevant even without this. But I am happy to let Linus make this decision. I just think it is a poor decision.