In the case of LibreSSL, it's probably not going to happen very soon; the OpenBSD devs are very much C programmers (and Ted Unangst already addressed this in the case of Heartbleed, though his methodology is the subject of some contention: http://www.tedunangst.com/flak/post/heartbleed-in-rust ).
While Ted's post has been criticized by a few Rust programmers (see: http://tonyarcieri.com/would-rust-have-prevented-heartbleed-... ), it still brings up the argument that one's language choice isn't a magic bullet. There's an adage (I have no idea who originated it) that's along the lines of "every 'idiot-proof' system underestimates an idiot's ability to break things", and that's worth considering here. Rust prevents a lot of bugs, but it's not a guarantee of security. One needs to understand the actual problem that needs solved, and this is where the OpenBSD devs are focusing with LibreSSL (and their various other projects); their security track record stands as a good testament of that notion of understanding trumping language choice.
This isn't to say that I disagree with you. Rust is readily poised to replace C in a lot of contexts (IIRC, one of the obstacles right now is the use of a different allocator, so trying to use a Rust library from C results in some performance overhead), and it would be nice to see it used in a lot more projects. Just bear in mind that moving to Rust isn't the only step that would be required to fix these sorts of security bugs.
Memory safe languages aren't bug free in terms of security bugs, as there are also logical errors, as shown by many Java exploits.
However, removing the typical C memory corruption errors out of the picture is already quite an improvement.
Rust and other system programming languages have more probability to succeed outside classic UNIX systems though, as UNIX and C go hand-in-hand and I doubt that will ever change.
The only non-classic UNIX is Mac OS X and it already has its own "Rust".
Well, the nice thing about Rust is that it's at least theoretically possible to swap out C with Rust without affecting very many things (at least not negatively, other than the duplicate allocators IIRC), so a Rusty Unix is at least plausible.
While Ted's post has been criticized by a few Rust programmers (see: http://tonyarcieri.com/would-rust-have-prevented-heartbleed-... ), it still brings up the argument that one's language choice isn't a magic bullet. There's an adage (I have no idea who originated it) that's along the lines of "every 'idiot-proof' system underestimates an idiot's ability to break things", and that's worth considering here. Rust prevents a lot of bugs, but it's not a guarantee of security. One needs to understand the actual problem that needs solved, and this is where the OpenBSD devs are focusing with LibreSSL (and their various other projects); their security track record stands as a good testament of that notion of understanding trumping language choice.
This isn't to say that I disagree with you. Rust is readily poised to replace C in a lot of contexts (IIRC, one of the obstacles right now is the use of a different allocator, so trying to use a Rust library from C results in some performance overhead), and it would be nice to see it used in a lot more projects. Just bear in mind that moving to Rust isn't the only step that would be required to fix these sorts of security bugs.