Re: Better compilers?
The second is that you almost always end up restricting the language features to some limited, safer set or replacing core functionality (e.g. malloc or the compiler) with something custom.
This is an important point. You can't have completely memory-safe C at the translation ("compiler", though C does not, strictly speaking have to be compiled) level, because you'd have to violate the C standard in various ways. For example, the translator can't tell how large an object with dynamic lifetime might be, nor how large an object passed by an external caller might be.
If it's a hosted C implementation, as most are, you have to provide malloc and friends. That's required by the standard unless it's a freestanding implementation.
So you might create a language which is similar to C with additional memory safety, but you're stuck with an uneasy compromise: something that isn't C enough to correctly translate and execute all conforming C code, but doesn't achieve the degree of memory safety you can get in something like Rust.
D is probably as good an attempt at a safer C as anyone's going to produce. C++, used in a careful, Stroustroppian manner, can achieve a decent level of safety; but C++ is also, as a language, required to carry a great deal of baggage. It's also huge (the C standard is large but comprehensible; the C++ standard defies the understanding of mortals), which makes it hard to reason about in general, and the vast majority of the considerable quantity of C++ code I've seen is rubbish, which suggests that many C++ developers find it difficult to be vigilant about their use of it.
No programming language is perfect. I like LISP and Scheme; I like OCaml and F#; I like Rust. I'm not particularly fond of Go, but I don't think it's objectively bad. I've enjoyed writing OO COBOL for .NET (which is not very COBOLy, to be honest), of all things. I've done a couple of non-trivial things in Java, and I don't mind working with it once I get back in the habit. I wrote a couple of academic projects in Javascript (for Reasons) and that was fun, though I wouldn't want to do anything big in the language, and third-party Javascript libraries are a plague. But all these have their faults, too.
Most of my work is still in C, and will continue to be for the foreseeable future.