The false premise
- There exists a feature called memory safety.
- Languages that have it are memory safe languages.
- Languages that do not have it are memory unsafe languages.
- Why but why would you ever use a memory unsafe language?
The reality
- There exist APIs and compiler features that influence how programs are written in many subtle ways.
- A topical example is malloc/free, which have so few constraints on memory allocation that programmers readily manage memory incoherently, leading to bugs.
- A topical example is the Rust borrow checker, which presents such stringent constraints that programmers alternately
- tie their programs into a Gordion knot of difficult to maintain lifetimes (a 'good outcome' with no memory errors, but still a problem when it's so difficult to update the program to resolve a security issue that the useful service is taken down instead, or that the security issue persists for longer than otherwise)
- dodge the borrow checker while not dodging serious memory misuse (bad outcome)
- dodge the borrow checker while leaning on other memory management strategies (generally a 'good outcome', with memory errors turned into reliable runtime panics)
- A topical example is the arena allocator, which encourages programmers to
- escape the false paradigm of stack (trivially management memory, but static in size and small) vs. heap (troublesome to manage memory, but dynamic in size and large),
- and to arrange programs so that memory is very easily managed as with multiple dynamic-sized stacks
- None of these "are memory safety". There are no "memory safe languages" or "memory unsafe languages". Rust, in particular, is not a "memory safe language".
- Memory aside, Rust's safety in the long term is likely to reflect
- short term success as Rust programmers are disproportionately interested in safety
- long term failure as Rust programmers approach the mean while Rust programs remain too difficult for a domain expert to audit. Will the medical equipment irradiate the patient or not? Will the plane fall out of the sky or not? Did the programmer correctly implement the specification? The borrow checker cannot answer.
The future
-- is double-entry bookkeeping. But for programming. A program that really absolutely must be safe is written twice, once by a programmer in a programming language, and once by a domain expert in a logical language, and the compiler formally verifies that these two separate descriptions of the program are a match for each other. There is no shortcut to this. There are no compiler warnings or compiler checks that can say that a program as written is actually as wanted. There is only double-entry bookkeeping.
Or even triple-entry bookkeeping, with elaborate tests as the third entry (not good enough by themselves to be the second). A program's source code is a description of how the program should behave. The tests are also a description of how the program should behave. The logical specification is also a description of how the program should behave. You can approach this level of safety today with SPARK and ATS, and the Rust community's interest in safety actually seems likely to manifest in formal verification there as well.
The personal
It was that last thought, about Rust's focus on safety and especially the energy of the community to come up with stuff like https://github.com/rust-lang/miri, is what encouraged me to finally learn it after having such a distaste for it. My experience was very positive. I enjoyed learning the language, which has laudible influences, a thoughtfully designed newbie experience, reasonable tooling, and very good documentation. I enjoyed using libraries, which were abundant and easy to use. I enjoyed writing software, which was satisfying, coming with a particular focus on lifetimes, avoiding copies, knowing whether a complex chain of function calls allocated memory or not, etc.
And then, I had Rust programs that I'd written, where I was obliged to look at the code and to maintain the code myself. My conclusion: this language does not have a future. All of those programs are gone now and I don't miss them.
