| "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. |
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.