I care less about programming language wars than I do about Vim vs. Emacs.
I do care about engineering decisions and attack classes and the security ecosystem around tech stacks -- from the compiler to the IDE to analysis tools to software architectures. So, I do like this recommendation to switch to any number of memory safe languages.
Of course, my most common refrain after embracing memory safety is that there's a wealth of other vulns and attack classes that manifest within such languages. The appsec work isn't done; it's just shifting attention to a different type of flaw. After all, the major exploits we've seen in the crypto world have been predominantly race conditions, bad assumptions, and poorly implemented workflows -- all within memory safe languages. And the OWASP Top 10 barely touches on memory safety as a major threat.
So, please do shift away from C and C++ as considerations for new software. But keep in mind that population of applications that still need to be secured -- whether web, APIs, or others -- are already on memory safe languages and already struggling with other types of flaws.
Check out the "Software Memory Safety" (PDF) from the NSA.