4 ms·

I think latency sensitive applications will usually prefer better performance and deal with safety issues, as opposed to better safety and deal with performance

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.

viraptor 1y ago
It's also a big difference in your environment. A desktop with spare power, decoding a video from an untrusted source? You probably want the safe version. 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.
- gafferongames 1y ago
  I think you're taking the term "safety" in rust a bit too literally. It's got bounds checking in it man. That's all. You can also write totally safe programs in C, or if you really want to be serious about it, write the program in F and use formal verification like this crypto library does: https://github.com/hacl-star/hacl-star https://github.com/hacl-star/hacl-star
  - viraptor 1y ago
    > It's got bounds checking in it man. That's all. 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 https://github.com/seL4/seL4/blob/master/CHANGES.md )
  - imtringued 1y ago
    If you are willing to use formal verification you can just turn off the bound checks in production so I don't get your point. Also, dismissing bounds checking as "just bounds checking" shows how delusional you are.
rand_r 1y ago
Yes, exactly. Latency is the killer feature. Doing a video call with extra 50ms of latency is noticeable.

viraptor 1y ago

It's also a big difference in your environment. A desktop with spare power, decoding a video from an untrusted source? You probably want the safe version. 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.

gafferongames 1y ago
I think you're taking the term "safety" in rust a bit too literally. It's got bounds checking in it man. That's all. You can also write totally safe programs in C, or if you really want to be serious about it, write the program in F and use formal verification like this crypto library does: https://github.com/hacl-star/hacl-star https://github.com/hacl-star/hacl-star
- viraptor 1y ago
  > It's got bounds checking in it man. That's all. 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 https://github.com/seL4/seL4/blob/master/CHANGES.md )
- imtringued 1y ago
  If you are willing to use formal verification you can just turn off the bound checks in production so I don't get your point. Also, dismissing bounds checking as "just bounds checking" shows how delusional you are.

rand_r 1y ago

Yes, exactly. Latency is the killer feature. Doing a video call with extra 50ms of latency is noticeable.