[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.

[vsgherzi]

I agree, unsafe rust is only meant to be used when absolutely needed. It’s up to the programmer. Frivolous use of unsafe should be rejected from any respectable code base.

I didn’t mean to say that without it the kernel would be irrelevant. I meant more that this is just one possibility for the future of the kernel and I think it’s important that we try as it has to always be better. Given the response from current maintainers I also question if the experiment should continue.