I think latency sensitive applications will usually prefer better performance and deal with safety issues, as opposed to better safety and deal with performance issues.
So I doubt it's any religious thing between c and Rust.
So I doubt it's any religious thing between c and Rust.
A farm of isolated machines doing batch transcoding jobs? Give me every single % improvement you can. They can get completely owned and still won't be able to access anything useful or even reach out to the network. A crash/violation will be registered and a new batch will get a clean slate anyway.
It's got bounds checking, lifetimes, shared access checks, enforced synchronisation, serious typed enums (not enforced but still helpful), explicit overflow behaviour control, memory allocation management, etc. etc. to help with safety. Far from "that's all".
> You can also write totally safe programs in C,
No you can't beyond trivial levels in practice. Even super human exceptions like DJB made mistakes and statistically nobody here is even close to DJB.
> use formal verification like this crypto library does
"Beware of bugs in the above code; I have only proved it correct, not tried it." -D.Knuth (That is - you can make mistakes in the spec too - see how many issues the verified sel4 had https://github.com/seL4/seL4/blob/master/CHANGES.md )
Also, dismissing bounds checking as "just bounds checking" shows how delusional you are.