1. I think a lot of people believe Rust will just type-check any old program and tell you when it has faults. So you can start with a bit of Ruby/C/Python, translate it to Rust and presto, all your bugs are exposed for the world to see.
In practice Rust's type checker accepts only a _very_ small subset of correct programs. I've been in a position to write some decent sized Rust code recently and it takes a shift in your mindset to start writing decent Rust code.
Even now there are patterns I'm unsure how to model in Rust. Arena allocation is a good example because it was partly the cause of Heartbleed too. Arena allocation in rust seems to require unsafe pointers and unsafe code blocks. You can look at Rust's standard library and see this.
2. The point being that the Rust language exposes unsafe code blocks and pointers. At some point you're going to hit those blocks (if nothing else in 3rd party code) and you're back to square one: You need to trust unsafe code that it is correct. It doesn't matter if that code is a VM or unsafe code.
The argument Rust devs make is that most of the time you would not need to use unsafe code and when you do, being explicit about it would make you more careful and think twice about it.
To me it makes sense. And the example you give here is very relevant. First you'd try to do it within the standard language bounds and only when you realize you can't do it that way, I'll resort to unsafe code. But now your very aware that this part of the code needs to be treated why extra care. So, to me, you're not completely back to square one.
I would even add, if care is taken to make that unsafe code really small it can even been generated by Coq for instance as stated in some comments here.
That said Rust might not be the best out there for the job but IMHO it shouldn't be dismissed to fast either. It is similar enough to C++ to allow a less painful transition for devs with the domain knowledge.
Would you not assume that the entire OpenSSL library would count as being in need of extra scrutiny? The point is that any time you let people directly access memory, they can, and often will, screw it up.
Ok, maybe we should make a distinction between, let's say the plumbing code and algorithms. Rust could help with the former. According to some comments I've read here it seems OpenSSL is using it's own abstraction of malloc/free (not that I have actually read the code). I suppose that this part of the code would be a suitable candidate for unsafe code with special extra care taken, then the rest of the algorithm does not not to be unsafe code. If you watch the video you might understand better what I mean : the ARC is unsafe but provide you with a safe abstraction for you to use in the checked part of the language.
Of course such a project must require extra scrutiny on all level and Rust does not resolves all the problems. I'd say pick your battles. Rust provide some interesting middle ground between C/C++ and a completely different language like Ada.
> It doesn't matter if that code is a VM or unsafe code.
What does matter is the amount of unsafe code to trust. It's much easier to check that a small area of clearly-marked unsafe blocks does "the right thing" than if your entire program is a gigantic unsafe block.
