5 ms·
Given that many 'memory safe' languages offer escape hatches for non-memory-safe code, shouldn't the answer rather obviously be "always"? Assuming no extra cons
by Octoth0rpe 4y ago
Given that many 'memory safe' languages offer escape hatches for non-memory-safe code, shouldn't the answer rather obviously be "always"? Assuming no extra constraints like compatibility with a large amount of non-memory-safe code, and that the language is actually fit for purpose (don't use js for kernel modules, nim as a procedural language in postgres)
- hedora 4y agoSadly, no, there isn’t always a memory safe language that is fit for purpose. For one thing, the article lists 5 memory management techniques. It is reasonably common for sufficiently large, high performance C++ code bases to rely on three or four of the things on that list, all in the same process. The compiler can only partially verify that the application is not crossing the streams by passing memory from one allocator subsystem into another. Also, memory unsafe languages are sometimes safer on some other dimension than the most obvious memory safe alternative. For instance, it is trivial to write C++ code that provides constant, non-null references (in the absence of UB), but completely impossible to express those invariants in the Java type system.