Presumably languages which default to optional instead of null with the default ergonomics being to “or_else” instead of “unwrap” will encourage safer error handling.
It works for me, but I don’t know if it is yet well known what the effect of developer UX on error rate is.
Nope, you are still not making sense. Just look at the "Facebook remotely disables all apps" issue. Both times it was issues deserializing - the deserialization wasn't unsafe or outright crashing, it was simply the SDK wasn't prepared to deal with the data it got.
I find that I can write code that is less likely to crash or fail more easily in some languages than in others. If this is not the case for you, I understand that it isn't compelling but that's okay. Not particularly looking for you to adopt anything.
UX things in some languages guide me to idiomatic code that is safer. And as engineers, we know there is no guarantee, only shades of improvement. But again, if language choice does not affect your program quality, so be it.
Impossible is a big word :). But while a C or C++ program tends to crash in the presence of an error, like with a segfault, a lot of languages just throw an error which you can catch. So you could proceed with the default values, if the file cannot be read correctly.
"can catch" doesn't give you anything, unless you actually do the catching.
C and C++ programs tend to crash in the presence of an error, but so do rust programs (panic), C# and java and js and python programs (unhandled exception). Some languages make it harder to footgun yourself for certain types of errors, but never all types of errors.
I have seen js programs (and similar stuff in other languages) crash because of something like
JSON.parse(response).list[0].string.length
where the response was valid json, just the .list property was an empty array (or even undefined because omitted in the json).
Does rust protect from such mistakes (because I know some people on here like to claim rust is the answer to everything)? Verbatim from their docs:
let v = vec![0, 2, 4, 6];
println!("{}", v[6]); // it will panic!
I'd guess it's exactly such type of bounds error at play with the Saumsung thing, from the mention of that empty <list/> element in the article.
I have written such code myself because I was lazy or distracted or "need performance" or "this can never be empty per spec" or "oops, my range calculation was off by one", tho luckily I didn't outright brick anything, yet.
There is one difference in Rust: they are so confident of their memory model, panic!() only kills the current thread. The exception is if it happens in the main thread it kills everything.
In Samsung's case, if they put the parsing of the telemetry config xml file in a separate thread the default Rust behaviour is not to kill the entire thing. Sending the telemetry back to servers sounds like something you would do in a separate thread, so perhaps it would have saved them.
Other languages with similarity strong memory models like Java / Python / Haskell could do the same thing of course. And in those languages programmer could just emulate it in any case. C / C++ with their weak memory models could not sanely do it. A programmer could emulate it in those languages by using separate processes if the OS supported it, but they would have to forgo shared memory.
Not a huge difference perhaps - but Rust's strong memory model does buy you something.
Oh please. C and C++ programs can be coded to fail gracefully and "a lot of languages" fail in unpredictable and unfortunate ways and shitty programmers still don't catch those magic errors. This is a matter of crappy engineering, not per se crappy language.
You can have programs crash in any language. However, it is the question, how well a program can recover from an error. Having a concept of error handlers in the language, which can catch conditions occuring inside the code they are calling, leads to more robust programmers.
Think of it as airbags and seat belts. Drivers, who don't make a mistake, wouldn't need them, but in reality shit happens, and they give us more survival chances.
You can argue about which syntax is best. But irrespective, having a perfectly good boolean already, but then comparing it to true or false to unnecessarily create another boolean is always just wrong.