[imtringued]

The importance of memory safety depends on whether your code must accept untrusted inputs or not.

Basically 99% of networked applications that don't talk to a trusted server and all OS level libraries fall under that category.

Your HFT code is most likely not connecting to an exchange that is interested in exploiting your trading code so the exploit surface is quite small. The only potential exploit involves other HFT algorithms trying to craft the order books into a malicious untrusted input to exploit your software.

Meanwhile if you are Google and write an android library, essentially all apps from the play store are out to get you.

Basically C++ code is like an infant that needs to be protected from strangers.

[menaerus]

Databases are a perfect example of an open-ended complexity space. SQL is a Turing-complete language and your users are programming their workloads against your database kernel. You (as a developer) know nothing about those workloads nor do you know what your users will want to do next. And you basically have to write the code so that it can virtually support any workload that can possibly exist. It's almost as if you're writing a compiler but with a virtual machine inside of its own OS but with the big difference and which is the ability to scale across millions of users (and data). There's probably not much software like that in the world.

And yet, no matter how complex database engines really are, my experience has been the same: the number of bugs related to memory-safety were extremely rare.