Re:Why you should, actually, rewrite some of it in Rust
by AnimalMuppet on Wednesday July 12, 2017 @08:18PM
(#14757813)
> It totally had UB, overwriting random memory, exceptions, etc. It was common knowledge in the operations that the app crashes randomly lots of times a day and has to be restarted automatically, to the point of this being considered non-issue.
Most fundamentally, that's a corporate culture issue. That should not be regarded as normal in any sane environment. (And, yes, such environments do exist.)
> The company actually has super smart C++ programmers (and I mean it!), submitting proposals to the C++ committee and having them accepted.
But not thinking it's a problem when the app crashed multiple times a day? That sounds like architecture astronauts, not good programmers.
> I know there are tons of them [data races] sleeping undetected in any multithreaded C++ code.
No. I've worked on real-time multithreaded code that had no data races, thanks to judicious use of mutexes. (Now, I can't prove that, and you could argue that they're there, and I just don't know it.)
It's possible to do much better with C++ than what you experienced - to write solid stuff that doesn't crash every day, still less multiple times a day; to write multithreaded code that isn't riddle with race conditions; and so on. Mostly, what it takes is a team (or corporate) culture that insists on quality code, from start to finish - good design, good development, good testing and debugging.
Most fundamentally, that's a corporate culture issue. That should not be regarded as normal in any sane environment. (And, yes, such environments do exist.)
> The company actually has super smart C++ programmers (and I mean it!), submitting proposals to the C++ committee and having them accepted.
But not thinking it's a problem when the app crashed multiple times a day? That sounds like architecture astronauts, not good programmers.
> I know there are tons of them [data races] sleeping undetected in any multithreaded C++ code.
No. I've worked on real-time multithreaded code that had no data races, thanks to judicious use of mutexes. (Now, I can't prove that, and you could argue that they're there, and I just don't know it.)
It's possible to do much better with C++ than what you experienced - to write solid stuff that doesn't crash every day, still less multiple times a day; to write multithreaded code that isn't riddle with race conditions; and so on. Mostly, what it takes is a team (or corporate) culture that insists on quality code, from start to finish - good design, good development, good testing and debugging.