@John > My take is the source language is hard to be careful with For that to be true you would have to be positing that 1) new languages are overused and 2) new languages are poorly designed and implemented. I say that because, if you look at things like memory corruption as a long-time flaw of old languages, those kinds of low-level mistakes are all *known* factors, thus it is *easy* to understand how and why you have to be careful with them. From what I read of the links in this article, there wasn't even a break down on whether or not the overwhelming factor explaining the vulnerability was lack of developer competence with the language being used. In my experience, the bigger factor by far is the near-universal adoption of agile software development methodologies. The idea of moving fast and breaking things is fundamentally incompatible with security. Eliminating low-level operations in a language simply means developers are going to get in over their heads with some *other* kind of operation that leads to a vulnerability (e.g., [Log4Shell](https://en.wikipedia.org/wiki/Log4Shell)). And while it might be tempting to classify such things as library/linkage issues, the root of that behavior is the agile metrics that favor just shoving things out the door at the end of a sprint if it merely passes functional tests. 320e937c7b764556ba8471936fdf96c6abadd6ffdd2699648d0b149158af75aa