3 ms·

First, things don't panic a lot in my experience writing Rust for the past three years. Second, when things do panic, it indicates a defect in the code that nee

First, things don't panic a lot in my experience writing Rust for the past three years. Second, when things do panic, it indicates a defect in the code that needs to be fixed. Aborting the program with a stack dump is the perfect behavior for seeing the state and the invariant that was violated and then figuring out the fix. Contrast this to C or C++ "limping along", usually until a later invariant causes a crash and being further away from and obscuring the true root cause, and we see why C and C++ code is generally still so bug-ridden relatively speaking. Fail-fast is not just a buzz word and program bugs are not recoverable errors. See https://joeduffyblog.com/2016/02/07/the-error-model/ https://joeduffyblog.com/2016/02/07/the-error-model/

pclmulqdq 2y ago
These arguments get said a lot and they are all fine in theory, but in practice, all code over a certain size has a tremendous number of latent bugs, even Rust code. At a certain scale, you are virtually guaranteed to be running in a degraded mode of some kind. If the consequences of those latent bugs are operational nightmares, that's a problem. Most people would rather be able to roll in at 10 am to debug a minor issue from logs and traces than get a page at 1 am with 1000 stack traces in it.
- morning-coffee 2y ago
  If your goal is to converge on correctly functioning software, you know, for the benefit of the users of it, then fail-fast can help. If your goal is to optimize the sleep patterns of devops people and make changes to code without testing before releasing it to production, yeah... do what you need to do. :)
  - pclmulqdq 2y ago
    You can have correctly-functioning software when parts of it are operating in a weird way. The complaint I have heard about Rust crashes is that the default behavior is to crash in any situation that could possibly be weird. By the way, the trade you're talking about is great for desktop software (especially for browsers), but server-side software at scale is a bit different. The borrow checker and all the Rust safety stuff is also completely orthogonal to most forms of testing. You don't get to do any less because your language protects you against a specific class of memory-related errors.
- SkiFire13 2y ago
  I wonder how you could realistically end up in those two situations for the same issue though.
- jamincan 2y ago
  > These arguments get said a lot and they are all fine in theory, but in practice, all code over a certain size has a tremendous number of latent bugs, even Rust code. Are you claiming this from direct experience, or do you have some data to back it up? Apparently the rollback rate for Rust code in Android is less than half that of C++. [1] 1. https://security.googleblog.com/2024/09/eliminating-memory-safety-vulnerabilities-Android.html https://security.googleblog.com/2024/09/eliminating-memory-s...

pclmulqdq 2y ago

These arguments get said a lot and they are all fine in theory, but in practice, all code over a certain size has a tremendous number of latent bugs, even Rust code. At a certain scale, you are virtually guaranteed to be running in a degraded mode of some kind. If the consequences of those latent bugs are operational nightmares, that's a problem. Most people would rather be able to roll in at 10 am to debug a minor issue from logs and traces than get a page at 1 am with 1000 stack traces in it.

morning-coffee 2y ago
If your goal is to converge on correctly functioning software, you know, for the benefit of the users of it, then fail-fast can help. If your goal is to optimize the sleep patterns of devops people and make changes to code without testing before releasing it to production, yeah... do what you need to do. :)
- pclmulqdq 2y ago
  You can have correctly-functioning software when parts of it are operating in a weird way. The complaint I have heard about Rust crashes is that the default behavior is to crash in any situation that could possibly be weird. By the way, the trade you're talking about is great for desktop software (especially for browsers), but server-side software at scale is a bit different. The borrow checker and all the Rust safety stuff is also completely orthogonal to most forms of testing. You don't get to do any less because your language protects you against a specific class of memory-related errors.
SkiFire13 2y ago
I wonder how you could realistically end up in those two situations for the same issue though.
jamincan 2y ago
> These arguments get said a lot and they are all fine in theory, but in practice, all code over a certain size has a tremendous number of latent bugs, even Rust code. Are you claiming this from direct experience, or do you have some data to back it up? Apparently the rollback rate for Rust code in Android is less than half that of C++. [1] 1. https://security.googleblog.com/2024/09/eliminating-memory-safety-vulnerabilities-Android.html https://security.googleblog.com/2024/09/eliminating-memory-s...