Absolutely. A common approach to programming bugs is to try and educate programmers to not make particular mistakes. A more effective approach is to redesign the language so those mistakes are impossible.
For example, the JSF C++ guidelines say not to use 'l' suffixes on numeric literals, because they look like a 1. D simply makes the 'l' suffix illegal, use 'L' instead.
A common approach to programming bugs is to try and educate programmers to not make particular mistakes. A more effective approach is to redesign the language so those mistakes are impossible.
Exactly. That's why I'm bothered by Rust being almost protected against memory errors, and Go being almost protected against race conditions. Even if you give up some performance, it's a big win to eliminate entire classes of errors.
(Still, both are way ahead of C/C++ in this area. So far, I don't think there's been a CERT advisory for a Go program. Rust is too new to be attacked yet.)
It has been (7) days since the last CERT security advisory for a buffer overflow in a C/C++ program.
A common approach to programming bugs is to try and educate programmers to not make particular mistakes. A more effective approach is to redesign the language so those mistakes are impossible.
Depends on what you want. Give me a powertool and I'll give a powerful result. Give me safety scissors and I'll take much longer, and the result will probably be inferior. And I can say with some certainty that both products will be roughly equal in terms of safety, because I pay careful attention to safety when designing and implementing systems. But the products will differ greatly in terms of feature set, extensibility, and robustness.
It's difficult to add safety without subtracting power.
For example, the JSF C++ guidelines say not to use 'l' suffixes on numeric literals, because they look like a 1. D simply makes the 'l' suffix illegal, use 'L' instead.