I think he has a point. Do we really need this specific technology from the future to prevent Heartbleed? No, because we have ASan and other things like that.
ASan is a runtime detector; it only works if you have a test case that covers the buggy thing, like in this case sending a malformed heartbeat request. OpenSSL pretty clearly didn't have a test case for that - if they did, they'd've caught the problem, with or without ASan. It's like the difference between a type system and unit testing.
You miss an important distinction between proof-based approaches (such as type systems) and testing (such as ASan): for any non-trivial problem it's impossible to test all potential inputs, and the inputs that trigger security issues tend to be ... unusual.
As Dijkstra said: "Program testing can be used to show the presence of bugs, but never to show their absence."
The Rust typechecker is a static analyzer, and thanks to the language's strict semantics it's more powerful and more reliable than any static analyzer that can be written for C or C++. The language also has a pluggable lint system, so that if you concoct your own correctness guidelines (say, "trigger a compiler warning whenever a buffer is reused"), you can easily implement it and distribute it as a regular Rust library so that others can benefit from it as well. See https://github.com/Manishearth/rust-clippy for an example of such user-defined lint passes.
We also have 'not using a custom malloc() wrapper that doesn't actually free memory as a wrapper around free()' to prevent Heartbleed, but instead of this technology being from the future, it's actually from decades ago.
