I guess the field I was imagining was greener than that. But yes.
In many cases you can just interface to the C libraries. But cross language coding has never been perfect, and yes, sometimes it's better to continue using the same language.
It's not hard to write an RAII wrapper around a C library, and the careful allocate/free is code you have to write either way (e.g. I'd write a wrapper in C++ if I need to use a C library with resource handling).
C is the easiest to interface with. Every language has to be C-compatible.
I would not choose C or C++ just because I depend on libfftw, or simdjson, or most other things. If the code that needs to talk to the library is less than 10% of the total program (exact percentage just made up), then I'd still use Rust.
So many of the CVEs against rust crates are actually against the bindings for things like ssl, glibc, and libcurl. I think accepting small growing subsets of ssl and curl for native implementation would be a good idea. And relibc too I suppose. Go went this route, and while it caused some headaches porting to new kernels, it has lots of benefits too.
That story seems to be about missing code/functionality, more than anything about a vulnerability. There is way more unsafe out there than there should be. Bindings are are one of the very few cases that must have it.
It depends on the company, the team skills, the tools they are used to have, the difference when moving into Rust, eg CUDA in C++ with NSight and Visual
Studio plugins from NVidia, versus Rust.