4 ms·
To add to that, there are some applications for which memory unsafety just doesn't cause that much harm. I worked on a very large C++ codebase that compiled to
by verdagon 4y ago
To add to that, there are some applications for which memory unsafety just doesn't cause that much harm.
I worked on a very large C++ codebase that compiled to webassembly, which runs sandboxed in people's browsers. It only talked to one (trusted) server.
Like any project, we had plenty of logic bugs every release. They would often result in odd artifacts on the screen and sometimes a crash.
Only 5% of our bugs were related to memory unsafety, and they also resulted in odd artifacts on the screen and sometimes a crash.
In other words, memory unsafety wasn't much of a concern in practice. It was as bad as any logic bug.
This was the main reason we stuck with C++, rather than spend SWE-years migrating to a more memory-safe language.
(I know this is ironic coming from me, who designs a memory-safe language full-time!)
- jolux 4y agoRunning inside a memory safe virtual machine is obviously safe though, that doesn’t mean the language itself is safe.
- dagmx 4y agoThe issue isn’t that patching and fixing code to be safe takes a ton of your own time, but it’s about the risk to everyone using your code. From security risks to simple crashes, C++’s unsafe nature has caused a lot of issues in production in my experience. From renders and apps that crash to subtle security bugs. Not having to focus on those when shipping software to customers means I can focus more on the actual logic and the associated bugs instead. I’m not getting back crash reports and CVEs that sucks up my time. My users in turn aren’t getting affected by my crashes and security issues. Every person who reviews my code can also understand the language guarantees and stop passing my code through that lens and instead focus their mental energy on the other aspects of my code, like catching logic bugs. The effects of a memory safe language extend very far