The poster sounds like a stick in the mud who is upset at the hubbub around the new fancy tool that potentially invalidates their sunk cost into an aging one.
"We have a plethora of static and memory checking tools: Valgrind, ASsan, Intel Inspector, etc." I'm not sure what to do with that argument. How is having a plethora of external tools (that you have to setup, configure and in the end not ignore) better than a compiler that prevents memory bugs?
The fact is, nothing like valgrind, asan, etc. can catch more than a fraction of memory usage faults. The only reliable way to avoid shipping them is by construction: write using contructs that can't have any. This turns out to be possible.
Rust and numerous other languages build this into the core language, but it is not the only way to get there, as much as Rust fans like to insist otherwise. But you anyway can't get there in C.
So where is the problem? Why I have to download ~2gb security updates that tries to fix memory issues. Not one but ~10. Every update is full of them. It still seems the new updates will have them too. My OS is so vulnerable. When it will be finally fixed?
Like with electron apps. Convenience for developers but who is concerned about the user?
6 comments
[ 3.2 ms ] story [ 24.8 ms ] threadRust and numerous other languages build this into the core language, but it is not the only way to get there, as much as Rust fans like to insist otherwise. But you anyway can't get there in C.
So where is the problem? Why I have to download ~2gb security updates that tries to fix memory issues. Not one but ~10. Every update is full of them. It still seems the new updates will have them too. My OS is so vulnerable. When it will be finally fixed?
Like with electron apps. Convenience for developers but who is concerned about the user?