I agree that not all of the things you list necessarily reduce errors, or that those that do increase productivity over the long run, because you sort of straw-

I agree that not all of the things you list necessarily reduce errors, or that those that do increase productivity over the long run, because you sort of straw-manned me a little bit there. Me, I don't love strong type systems. But garbage collection doesn't fall into that category. As for state, the concerns there are confined primarily to concurrent systems, and about a gazillion people have discussed its problems with greater eloquence than I can muster (Joshua Bloch comes to mind). But you're a great programmer--no sarcasm intended--and if you say you can produce a great concurrent system and still carry around a ton of state then I believe you. I'm genuinely looking forward to the fruits of your labor. Most people, myself included, can't. The goal isn't to twist yourself or your users into a pretzel trying to build a language that prevents any error whatsoever from occurring, as far as I'm concerned. The goal is to produce a language that shrinks the potential for bad stuff on the downside and encourages good practices (and stays out of your way) on the upside. C did, in its day, accomplish both things admirably, and for some tasks it remains the best tool. It does not, however, follow that all of its shortcomings are in fact virtues, and that those who say otherwise are marketing.