[BlinkenBlinken]

Doesn't solve sloppy programming practices.

Being programmed in C or Rust is a non discussion. Using both in the same kernel source complicates code unnecessarily.

[nevi-me]

There hasn't been a convincing argument so far that Rust is a net negative for the Rust kernel from a security perspective. Sloppy programming practices and say sloppy review practices will exist in any language. What we're hoping for is fewer "oops, I used that thing after it no longer existed".

"Complicates code unnecessarily" can be met with a counter that it's necessary for the memory safety of the future millions of devices out there.

If Microsoft and the Linux Kernel release security updates periodically, and people's research says that around 70% of those updates are addressing memory safety issues, "unnecessarily" starts to sound more like a necessity.

We have to get to a point where resistance for the sake of resistance becomes unproductive.

[pornel]

Rust does prevent a lot of cases of "sloppy" code. In the safe subset sloppy use of pointers won't compile. Destructors run automatically, so even sloppy code is unlikely to leak. Optional and Result types make it harder to be sloppy with error handling. The type system won't let you handwave immutability or thread-safety.

[UltraViolence]

I always tend to think: "C is merely high-level assembly" with all the warts and bumps that come with it.

C is a poor choice for large software projects, because of its fragility (high-level assembly, remember).

The real problem lies in the fact that some obstinate developers refuse to trade even one iota of performance for security. Without that we wouldn't have the mess we're in today! It's relatively easy to develop a programming language that's memory and thread safe, but at the cost of some performance.

That's why Rust was developed: to get the same performance as C without the drawbacks. It does this by simply disallowing you to write dangerous code. Underneath it's simply C code, if you will.