|
|
|
|
|
|
by pron
1220 days ago
|
|
|
> most programmer convenience is sacrificed on the altar of "never crash". This makes it a good choice for sending a rocket to space When it comes to safety- or mission-critical software, crashing due to a dangling pointer, a stack overflow or a failed allocation are equally catastrophic, and not crashing but producing a wrong answer due to an algorithmic error is also equally catastrophic. In fact, producing the correct answer late can also be just as catastrophic when the system is real-time -- we don't care if the operation takes 1ms or 99ms, but if the deadline for emitting a control command is at 100ms, emitting it 100.001ms late is just as catastrophic as a crash (while completing the calculation in 20ms or 95ms is equally good). Never crashing for any reason, never producing a wrong result, and never producing a correct result late are all equally critical. How are such systems written? They normally require very simple code and very simple algorithms -- to make analysis by tools, and even more importantly, by humans as easy as possible. Any compiler magic or implicitness in the code may be problematic (possibly including reference-counting if a bound on deallocation time cannot be guaranteed). We don't want to make code as fast as possible, but as non-surprising and as predictable as possible. |
|
|
Similarly the worst bugs can be crashes (random, non-deterministic, release-mode only, timing sensitive heisenbugs), or they can be undetected algorithmic errors.
It entirely depends on the specifics. But either way, Rust's tradeoffs are easily worth it in terms of eliminating bugs unless you really don't care.