My list of "things I hate about C" is about 4 pages long now, after many years in embedded development (and a few in scientific computing prior to that). As soon as a viable replacement for it comes, I'm going to get drunk, ritually burn K&R's "The C Programming Language" then get drunk again. But I've been waiting for that day for a long, long, long time, and there's still no sign of it, not even with Rust (<i>maybe</i> with Go but we'll have to see).<p>I cannot think of a single systems programming language that has not vowed to put an end to all this buffer overflow and dangling pointers mess. The ones I tried so far (I think there's a dozen...) failed because of at least of one of the following items:<p>* Some of them mainly achieve safety by forbidding any unsafe read or write -- and then when you <i>have</i> to do a read or a write, they implement that by cleverly eschewing a protection mechanism or by isolating everything in an unsafe area. The former is disastrous because you can have bugs that eschew the protection mechanisms, too (see Heartbleed -- which can be <i>perfectly</i> replicated in Rust or Go); the latter, while useful in most application software, is next to useless in my day to day activity, where I have entire <i>modules</i> that consist of nothing other than unsafe reads or writes. At that point I might as well be using C.<p>* Others mainly achieve safety through a complicated system of annotations ("this parameter must not be NULL") or a type system that makes certain guarantees ("these parameter can never be NULL"). The end result is a system of annotations and/or types which you can describe in about as much space as The C Programming Languages takes to describe the whole language. Barring the fact that my memory is limited after ingesting C++, real life experience shows that "more complexity" is how bugs get introduced, rather than resolved. Except that the new problems don't arise because a pointer is pointing where it shouldn't, but rather because 1 == 1 returns False for certain types of 1 or something.<p>* Aaand some of them simply delude themselves through clever sandboxing and protected writes, ignoring the fact that the sandboxing back-end is C all the way and can be exploited. Except it's so mind-boggingly complex that fixing it is incredibly complicated.<p>Historically, there have been many instances of <i>operating systems</i> written in high-level (ish) languages. Hell, there are operating systems written in Common Lisp. It can be done. People haven't flocked towards high-level languages despite 30 bloody years, if not more, of operating systems written in high-level languages because it turns out you usually can't do it unless you turn most of those fancy protection features off. At which point you end up with C, only with a more complicated syntax, and why the hell bother?<p>The key to writing secure software that doesn't crash <i>is still</i> in correct programming. Tooling can help, but no language, no matter how fancy and hand-holding, is going to compensate for that.