I wouldn't put Python on that list because of how many packages are wrapped up C/C++ code. I know the same is done with Java and JNI but the pervasiveness of it is not at the same level.
> Even with a memory safe language, memory management is not entirely memory safe. [...] Memory safe languages can also use libraries written in non-memory safe languages and thus can contain unsafe memory functionality. Although these ways of including memory unsafe mechanisms subvert the inherent memory safety, they help to localize where memory problems could exist, allowing for extra scrutiny on those sections of code.
Which I suppose is a reasonable way to put it. It's been said elsewhere, but my read of this document is that this is not a _definitive_ list of languages you should use, but rather a list of languages that make it much more difficult for programmers to introduce memory-safety bugs.
Maybe they're using the other golden rule: All languages starting with a P are old, crusty and should be avoided.
Anyway, even without C extensions a malicious input might trigger a memory related vulnerability in the interpreter. A compiled program written in a memory safe language could suffer from a compiler bug. Did it happen to Go and Rust?
Really, in the long term, "unsafe" and FFI interfaces should be removed from C#, Java, and Rust. That's the only way to be sure. in fact, I'd be willing to bet that in the short to medium term, with this recommendation, government contractors will soon be required to submit code that does not use these facilities. If you can't do it in C#, use Rust, if you can't do it in Rust, use Java, but you probably will no longer be allowed to pull in that wiz-bang c++ library.
It’s essential to doing many things.