"For example, C programmers don't trust anything written since K&R." That is an incredibly broad generalization. Perhaps you were implicitly assuming some qual

"For example, C programmers don't trust anything written since K&R." That is an incredibly broad generalization. Perhaps you were implicitly assuming some qualifiers? :) --- "..that's why we have linters, static analyzers, style guides, compiler options and warnings.." But all those things are still just glorified retrofits on the job of the language. Are there any examples where a new library in a new domain adds inabilities that weren't originally enforced (or even conceived of) in the language? One example I can think of is reading/writing files. The original C had simple numbers for file descriptors, which meant that in a large application you might try to read from a write-only fd, or vice versa. The C++ standard library solved that by creating separate types for istreams and ostreams. No reason we couldn't apply that idea to C as well. On a tangent, I'm fascinated by the fact that Go hasn't bothered to steal that idea. For example, a goroutine can read or write any of the channels it has access to. If you try to juggle too many at once, that might cause the odd typo bug. It'll be interesting to see if source/sink channel types ever get retrofitted to Go in a decade or so.