[Ygg2]

> And as as the Cloudflare incident showed, a Rust unwrap can have equally bad consequences.

Arguably less bad than silently corrupting your data and forcing you to do CAPTCHA everywhere.

Which is what the parallel Perl(?) component was doing at the time.

Rust solution gave a clear signal something was wrong, the other solution was slowly annoying everyone and pushing them away.

[uecker]

A major global internet outage can certainly considered a "clear signal". Still not sure this was a good thing though.

[Ygg2]

It's not an ideal thing for sure, but between loud bang and silent corruption, I'd probably take loud bang. I.e. I'll take a panic rather than the method return 43 when you pop the null member from the stack.

And the Rust wasn't the root cause but corrupt configs were being erroneusly duplicated.

[uecker]

I guess this depends on what you might corrupt (if it is not valuable but irrelevant intermediate state it might be ok) and what the consequences of an outage are.

In any case, I largely tend to agree with you that this is better in most scenarios (not for the cloudflare incident though). But a segfault in C for a null pointer dereference would have exactly the same result, which is why null pointer dereferences are a terribly example if you want to show the advantages of Rust.

The only example I know where I think Rust clearly has a real advantage are lifetimes.