[kalekold]

Here's Linus' take:

  You need to realize that  
  
  (a) reality trumps fantasy  
  
  (b) kernel needs trump any Rust needs  
  
  And the reality is that there are no absolute guarantees. Ever. The "Rust is safe" is not some kind of absolute guarantee of code safety. Never has been. Anybody who believes that should probably re-take their kindergarten year, and stop believing in the Easter bunny and Santa Claus.

https://lkml.org/lkml/2022/9/19/1105#1105.php

  If you cannot get over the fact that the kernel may have other requirements that trump any language standards, we really can't work together.

https://lkml.org/lkml/2022/9/19/1250

[ducktective]

> The "Rust is safe" is not some kind of absolute guarantee of code safety

Exactly. Some people act like we don't have the whole branch of "formal proofs" in CS. Memory safety is just once aspect of program safety.

Like, IMO, programs written in Coq, F* or even C programs verified by Frama-C are much more "safe" than Rust programs that advertise their "safety" on the mere fact that they are written in Rust.

[UltraViolence]

The reality is that people are adding critical code to the kernel and surrounding infrastructure (OpenSSL) on a Friday night after a long weeks work and never bother to look at it again.

We absolutely need something like Rust to cover our backs!

[pclmulqdq]

The idea that Rust can solve this problem is ridiculous to me. The types of bugs that sleep-deprived contributors writing fire-and-forget code will make will just shift to something that the borrow checker doesn't help with.

[unrealhoang]

So, no bug that the borrow checker can help with? Sounds like a big win to me, why is it ridiculous?

[pclmulqdq]

The parent comment implied that this meant that there would be fewer bugs. That is definitely not what happens.

The factor that actually generates the bugs is the tired person writing code they will never read again or use. The borrow checker won't help with that.

I write code with different types of bugs in C, Go, Rust, Javascript, and Verilog, for example. I rarely write code with no bugs, especially when I have no real connection to the code.

[unrealhoang]

GP comment implied there would be fewer exploitable bugs. That is definitely what happens.

If you think there's the same amount of severe exploit from software written in Go/Java/Javascript and software written in C/C++, you are just factually wrong.

70% of exploitable bugs from large company products (M$, Apple, Google) ARE memory safety bugs.

[howinteresting]

The idea that people will just shift to other kinds is ludicrous. There isn't a fixed quota of bugs per developer-hour. In my personal experience, Rust code absolutely has fewer bugs than most other languages.

Several large surveys have found that approximately 70% of bugs in C and C++ projects are memory safety issues.

[UltraViolence]

It's not ridiculous, it's a proven fact! Rust obviously won't stop logical errors, but it will put an end to the almost unending cue of memory and thread related bugs.

Mind you that Firefox, for example, has been around for 17 years. Every month I get security updates fixing multiple memory holes in the code each of which could potentially allow anyone to take over my machine. Seventeen years!! They must have fixed hundreds if not thousands of such bugs by now, and every month more are repaired by updates.

We'd have none of those had it been written in Rust.

Also mind the time saved by developers not having to hunt for such (hard to track down) bugs!

[cesarb]

> We'd have none of those had it been written in Rust.

Except for memory issues in JIT-generated code from Javascript? Not all browser vulnerabilities are caused by memory safety issues in the code generated by the Javascript JIT, but several of them are (particularly "type confusion" vulnerabilities). Rust might help avoid vulnerabilities in the code generator, but not in the generated code.

[arunc]

FWIW, Walter Bright have been, for years, proposing the C standard to fix the billion dollar mistake in a backwards compatible way. Stroustrup is the head of the C standards committee, just saying.

[eps]

Typo? Stroustrup is not even a member of the C standards committee.

[pjmlp]

Stroustrup voice counts one vote like everyone else on ISO C++, doesn't matter what role he played on the language creation.

Also the current head of the standards comittee is Herb Sutter.

[belgesel]

Can you elaborate on that, couldn't find the proposal, I want to learn more about it.

[shp0ngle]

Those posts are actually more substantive and less negative than they might seem from these blurbs.

It’s not that Linus is against Rust at all, just clearing up some disagreements.

[elktea]

I'm not sure how this relates to the post, can you elaborate?

[bayindirh]

Many of the Rust "evangelists" thinks/behaves like Rust's guarantees are absolute and leads to absolutely unbreakable software by default, and advocate that the language is the silver bullet combining abilities of C, C++ (depending on application) without any of their downsides.

When you hit a limitation you really need to implement in Rust, they say "Hey, there's unsafe{}, use that". Also, they advocate that unsafe{} is equal to C/C++ in programming freedom, which is again not.

When they're reminded that reality is not like that, they get upset and defensive. This comment is a nice flag to remind this reality.

I congratulate Rust for being what it is, but it's not a silver bullet and it's not the next C or C++. It's just a very nice programming language for various applications.

Being all shiny-eyed doesn't work in CS or programming in general, and also hardware doesn't work like that (a deterministic, perfectly good behaving, spec-obeying magic box with some included smoke for higher performance).

[pizza234]

> Many of the Rust "evangelists" thinks/behaves like Rust's guarantees are absolute and leads to absolutely unbreakable software by default

Can you point to (high-profile) evangelists that actually push this view? I think the people you refer to are a loud minority of developers who possibly don't even write professionally in Rust. I've never read or heard this position from experts.

[bayindirh]

While the people I talk with are not high profile evangelists, all of them are using Rust in their professional life for work.

Maybe the messaging should be clear, and hype should be better controlled from top to bottom, because I never talked with anyone who doesn't casts stones to C & C++ and badmouths it while saying that Rust is the one, and only, and the last savior we need.

BTW, I'm not against Rust, but I don't use LLVM. I'm waiting gccrs to dive into the language.

[pjmlp]

> I never talked with anyone who doesn't casts stones to C & C++ and badmouths it while saying that Rust is the one, and only, and the last savior we need.

So here is one, Ada was already that saviour in 1983, and in every use case where using a GC is an option, there are already plenty of options besides Rust.

Also until Rust compilers get fully botstraped, knowing C++ is a requirement to contribute to the compiler's backend.

[c-cube]

Ada is cool, but as far as I understand it doesn't give you memory safety in the presence of dynamic allocations? Unless you use recent improvements to spark? It's hardly a superset of the safety features rust has.

[howinteresting]

Has Ada ever been the most loved language on the Stack Overflow developer survey for seven years in a row?

There are plenty of options besides Rust, but none that have & and &mut which eliminates many classes of bugs in both multithreaded and single-threaded code.

[pizza234]

> because I never talked with anyone who doesn't casts stones to C & C++ and badmouths it while saying that Rust is the one, and only, and the last savior we need.

I do definitely cast stones on C/++, especially considering that a C project I've rewritten in Rust uncovered several memory safety issues from the very first run. Another C project I've approached also showed C-specific issues from the very beginning.

On the other hand, I don't define Rust and the savior and so on; to be specific, memory safety is a very serious issue, but not the only one, and memory safe languages solve a very serious issue, but not all the issues. Additionally, I think Rust is a niche language; other memory safe languages may be more productive for the majority of the use cases ("webcrap", like a famous software engineer described :)).

Now you know one!

[howinteresting]

I mean I'd personally rate the opinion of people who actually use Rust higher than people who don't.

Rust isn't a silver bullet but it does shift the balance materially.

[falkaer]

I'm curious, why not use LLVM?

[bayindirh]

I'm a big GPL advocate, and publish I everything I can publish under GPLv3. Also, I want the code I publish to be able to be built with openly available tools. In other words, I want my software to be free and can be easily reproduced/built. This is the first aspect.

Second aspect is I don't like the behavior of LLVM ecosystem which is trying to subtly EEE gcc toolchain.

Lastly, I don't desire to be able to build a project I developed, or cloned to be only can be built with "clang/llvm/20201024+somecompanyClosedGitBuild20210514+bp1" which is available in binary form for a single distribution for a specific architecture. I have experienced SDKs and other software like that, and I don't want to go through again, or put anyone through that hoops.

[sebzim4500]

>Many of the Rust "evangelists" thinks/behaves like Rust's guarantees are absolute and leads to absolutely unbreakable software by default, and advocate that the language is the silver bullet combining abilities of C, C++ (depending on application) without any of their downsides.

Where are these people? I'm not doubting that they exist, but I've never come across one and I've been in the rust community for several years now.

[howinteresting]

This is misunderstanding the point of unsafe.

All memory-safe languages in existence have safe abstractions built around unsafe code. For example, most JavaScript runtimes are written in C++. The point of unsafe Rust is to be able to use the same language to write both safe and unsafe code.

On the flip side, almost all C and C++ is unsafe code. The point of unsafe Rust is to be able to reserve brainpower for small subsets of code while having a relaxed posture towards most of it.

[ladyanita22]

> When you hit a limitation you really need to implement in Rust, they say "Hey, there's unsafe{}, use that". Also, they advocate that unsafe{} is equal to C/C++ in programming freedom, which is again not.

I'm interested. How does rust unsafe give you less freedom than let's say c or cpp?

[steveklabnik]

Rust's unsafe still needs to uphold the rules of safe Rust. It's not a license to just do whatever you want.

There are often ways to do whatever you want, but it's not as simple as "I have a raw pointer now let's goooooo."

I'd describe it as different, not "less", but I wasn't the one who said it originally.

[ziddoap]

One is a post about Rust in the Linux kernel, and the other is Linus talking about Rust in the Linux kernel on LKML.

What would you like elaboration on? The relationship seems pretty clear to me?

[phist_mcgee]

I see Linus has slightly tone down his ad hominem, but it's certainly still linus typing these words.