Speaking of corrosion, maybe we should be building systems with a language which avoids most of the problems of C.

The trouble with that otherwise perfectly reasonable position is that no such language exists yet that doesn't have its own significant problems of one kind or another.

I'm hopeful that this situation will finally change within the next decade and that C and C++ can be honourably discharged as soon as possible thereafter. However, I don't see this happening until newer languages with sounder foundations -- Rust comes to mind as a promising example -- have entered the mainstream. Until then, the ecosystem around C and C++ has too much momentum for a lot of projects to switch to more experimental technologies even if those technologies have advantages in terms of robustness.

I think that the OpenBSD team has more than definitively shown that C isn't a problem, programmers' attitudes is the problem. While I disagree with them on the premise of upgrade early and often, I do agree with them on active reviews, active documentation, and enforcing code hygiene, which prevents the sort of problems that proponents of other languages harp on about when talking about C.

> I think that the OpenBSD team has more than definitively shown that C isn't a problem, programmers' attitudes is the problem.

To err is human, no matter what your attitude. While having the correct attitude can help, this line of argument - that it's the programmer fault and not his tools - is part of the very attitude that causes problems!

Any decent programmer embraces the fact that they'll make faults - and beyond simply trying to improve, they'll also embrace tools that help them compensate. Such as static analyzers. Fuzzing frameworks. Safer programming languages.

Perhaps they'll choose tradeoffs that sacrifice some of these options - I certainly do, coding in C++ all day, a language with at least 40 references to "undefined behavior" in the '03 standard alone. But that doesn't mean those tools aren't worth considering.

> I do agree with them on active reviews, active documentation, and enforcing code hygiene, which prevents the sort of problems that proponents of other languages harp on about when talking about C.

I see zero inherent reason to rely on extreme vigilance by programmers to catch errors that better tooling can catch without having the occasional shared blind spot where 5 programmers all miss an uninitialized variable.

You can help use these to help compensate for C's weakness if that's a tradeoff you need to make, but that's quite an opportunity cost - leaving them with far less time to catch other logic bugs and ship features.

There's a reason nobody preaches about how it's going to be the year of the OpenBSD desktop (and that's not a knock at OpenBSD!)

Vigilance also requires the right knowledge. A coworker recently revealed to me he'd only recently learned that C++ member variables will generally have unspecified values if you don't initialize them. He thought other threads were to blame for garbage values.

Every now and then, I check to see if any of the compilers we're using have added a warning I can enable that will catch leaving members uninitialized after a constructor completes. So I can enable it. And configure it as an error. So everyone who builds the code knows there's a problem. Immediately.

So far, no dice.

...bringing up OpenBSD is interesting. Isn't there an email from de Raadt floating around that says that review, etc. aren't enough, and that's why they use ProPolice, W^X, randomized malloc, etc.. Tools which pretty much only exist as a stop-gap for C's horrible security record.