False.

* Manual memory management errors constitute 40% of all security bugs (C/C++)

* Null pointer errors constitute a significant cause of bugs (C/C++/Java/etc., anything but Haskell)

* Incredibly verbose languages require more lines, and line count has been shown to correlate with bug count (C/C++)

* Strong, statically typed languages with arity validation reject entire categories of bugs, which languages like Perl, JavaScript, and Ruby are famous for mucking up. Twenty thousand unit tests can save you from having to write one type signature. Can have variable name typo errors in Python, but not in Java, for example.

* The vast majority of shell programs neglect to even enable available `set` robustness checks, and therefore contain control flow and input validation problems.

* Early versions of many languages lack an unindexed `foreach` iterator, which leads to many unnecessary off by one errors. C++17 and C++20 are distinct languages with distinct bugs. Same for ECMAScript 3 and ECMAScript 5 and ECMAScript 6.

* New programmers in most languages will mistake zero based indices for one based indices. Old programmers will mistake one based indices for zero based indices (Lua, LISP).

* Languages with immutable by default data structures (Clojure) rule out entire categories of bugs, that other languages encourage.

* Shell and GUI languages are uncommonly unit or integration tested. Any script written in sh or Cucumber etc. etc. is very likely to contain bugs compared to more library oriented languages. The same applies to other commonly un-tested code (in the fuzzer complete sense): Client side JavaScript snippets, Emacs and Vim configuration, SQL queries, text editor plugins, and other spare tidbits of code.

* Programming languages with very small userbases are unlikely to mature enough to manage bugs, such as the custom language used for Fallout 3 crafting scripts.

* Fewer off by one errors in JMP instructions when the language emphasizes high level control flow structures such as `if`. Shrug.

* Fewer collection implementation bugs in languages that provide them in the standard library. What's that POSIX sh, you barely have arrays (`set`) and hashmaps (`env`) ? Or when a language has an array type but no mathematical set type other than a hashmap. Yeah, you're gonna have a bad time.

* Lambdas. In JavaScript and Go, you will accidentally enclose parameters by value rather than by reference. In C++, you can accidentally specify by value or by reference. In FreePascal, you don't even have lambdas.

* Show me a segfault in pure, non FFI, non-unsafe Rust.

A low level, verbose language like C is going to contain many more bugs than a higher level language like C++, that automates away and guards against more kinds of bugs, for the same given level of application complexity.

One could try to twist the natural correlation between programming language and bugs into an argument that says, "A programming language has an associated maximum line count above which at least one bug is 50% or more likely to be present." But in practice, programs never get shorter, they only gain lines and therefore, bugs. And so, starting with an appropriately expressive language for a given project will lead to more capabilities with fewer bugs. There's a reason we don't write everything in assembler.

One could make an argument that each language encourages different kinds of bugs, and that it may be difficult to estimate the relative frequency of say, mutation bugs in Go versus memory leaks in Rust. Fortunately, we have security incidents as a historical body of evidence. And the evidence points to manual memory management errors as a top problem in security bugs. Less critical bugs get less attention, though any program not written in a proof assistant language (Coq et al) will have bugs.