In electronics, we have parts which need their SOA (safe operating area) respected by the design, or they will catastrophically fail (melt, vaporize, explode, catch fire). We also have safe parts that have features like thermal shutdown, or output current limiting.
That's kind of similar to safe versus unsafe language features.
You still have to respect the operating parameters, because if the part goes into thermal shutdown or current limiting, then your device doesn't perform properly.
When the device doesn't work properly, even though there is no smoke coming out of it, it can still take time to track down the problem.
When using a safe language, we similarly don't necessarily want the user to be exposed to the raw safety mechanism going off, which could have consequences like terminating the image, with the loss of unsaved data, and interrupted workflows.
Typically, in modern safe languages we have some decent choices for handling and recovering from situations like that, so we don't have to be cluttering every operation with conditionals that check for exceptional situations.
That's kind of similar to safe versus unsafe language features.
You still have to respect the operating parameters, because if the part goes into thermal shutdown or current limiting, then your device doesn't perform properly.
When the device doesn't work properly, even though there is no smoke coming out of it, it can still take time to track down the problem.
When using a safe language, we similarly don't necessarily want the user to be exposed to the raw safety mechanism going off, which could have consequences like terminating the image, with the loss of unsaved data, and interrupted workflows.
Typically, in modern safe languages we have some decent choices for handling and recovering from situations like that, so we don't have to be cluttering every operation with conditionals that check for exceptional situations.