Well they would use `unwrap` if they were lazy, but at least that would be quite visible in the code and would not result in undefined behavior due to operating on a null value. And there might be a group of developers who first choose to use .unwrap. I hope it is the minority.

Given how easy it is to just forward that error to the caller, I think most Rust developers would just choose to do that.

While dereferencing a null pointer is technically UB, it practice it leads to a safe trap. So .unwrap is the right comparison. If you always forward the error to the caller, it will also just lead to some random error message at some point, not really different to a crash.

> There's no protection for not checking return values, and it's probably not even possible to protect against (in entirety)

That's exactly what you get with Result and Option, it's impossible to forget.

Compare:

    char* hash = crypt(key, salt);

    // We crash here on the hash derefence, it's no clear from the code
    // that we were supposed to check for NULL or that we forgot. 
    if (!strcmp(hash, expected)) {
    }

To:

    let result: Result<Vec<u8>, Error> = crypt(key, salt);
    // We MUST write this line, which is a very clear signal
    // that we can panic here.
    // This can be grepped for or forbidden.
    let hash: String = result.unwrap();

    // if result == expected { would type error
    if hash == expected {
    }

That's exactly what I mean. And I have seen a huge amount of unchecked unwraps in production code in the past years

Sure, but it's far better than the C code and I don't think in Rust a library would start returning `Ok` with sentinel values to "fix" shit calling code. Maintainers would, rightfully, tell people to fix their code.

Don't get me wrong, I think rust has some great features and does some things extraordinarily good. But at the same time I can see that for 99% of cases it's just as prone to bugs, including security and supply chain attacks, as any other language. I think I could just as much argue that any "->" is clearly de-referencing that needs checking, which is also pretty easy to see.

Agree to disagree I guess :)

this is theoretically, empirically, and objectively wrong. akin to saying that you can get into an accident in a truck as well as a motorcycle, so in 99% of cases there is no difference in safety.

different kind of programming languages change the kinds of bugs and their properties, but it does not change the amount of bugs per line of code. in respect to C and rust for example, rust may have less memory bugs - which LLMs seems to be able to spot now - but it did increase supply chain attacks for example.

> but it does not change the amount of bugs per line of code

You are really uninformed: different programming languages have very different volumes of bugs per line of code

With all the respect but I don't think I am: https://arxiv.org/html/1901.10220v2

that only tries to show a single study is flawed, nothing else

do you think bugs/loc is the same between brainfuck and rust?

> that only tries to show a single study is flawed, nothing else

no the study failed to show any difference in bug count for a specific set of common used languages, where C and Python were both part of the dataset.

I don't think programming languages have a big impact on bugs per line when every line is written by a human. Now given that I was talking about bug counts, not severity.

it showed errors in the methodology of an earlier study, it did not produce a novel result.

kind of reminds me how the "research" suggests that there are no practical differences between dynamically typed and statically typed languages...except we know from practical experience that there is, and the literature there is horribly flawed.

we have real-world evidence that rust leads to significantly less bugs in the real world

https://blog.google/security/rust-in-android-move-fast-fix-t...

> it showed errors in the methodology of an earlier study, it did not produce a novel result.

It showed that there's no big difference. From the link:

> Combining corrections for all of these aforementioned items, the reanalysis revealed that only 4 out of the original 11 languages correlated with abnormal defect rates, and even for those the effect size is exceedingly small.

--

> we have real-world evidence that rust leads to significantly less bugs in the real world

no, we only have evidence for memory bugs, that's not what I was talking about

[delayed]