Most projects don't need C, I'll agree. But I have a hard time seeing how a language that is on a 1:1 to 1:5 statement-to-machine-instruction language will be d

Most projects don't need C, I'll agree. But I have a hard time seeing how a language that is on a 1:1 to 1:5 statement-to-machine-instruction language will be displaced by a language that is safer while being at least as efficient and at least as expressive. If you say "but I don't need a 1:1 to 1:5 ratio..." THEN YOU'RE DOING IT WRONG. C isn't broken. Gah. Why does everyone have such a hard time understanding that? The language does //exactly what you tell it to do//. If that's overrun a buffer, then that's what you get. If it is fallthrough a switch statement, that's what you get. If it is typecast a block of memory that is too small to hold the structure, then that's what you get. In short, for many programs, that means doing stupid things at some time. For many programs, edge cases aren't considered at all. Blame C? It let me? For every single one of the "warts" of C, there is also a usecase. This is why it will not be "fixed" and why it isn't "flawed". To remove them is to remove a useful function that could otherwise cause more machine code to be needed. THIS IS THE KEY. Minimizing machine code (overhead). If you aren't good at managing these edge cases, don't need native code, don't need interop with other code, can take a performance hit, or don't want to use automated tools to help you, then don't use C for large programs. Take it for what it is: a low level, mostly portable, mask over assembly. Stop complaining about C, start complaining about programmers.