I'm looking at https://www.openssl.org/news/vulnerabilities.html and it makes me thing "OMG, this thing has a serious bug every month". I understand that cryptography is hard, so I'm not criticizing people working on it or anything, but just thinking about it aloud and considering my options.
In the past I was going an extra mile to get openssl working in my rust projects (need to build it from scratch for musl builds that I usually want), and kind of ignored rustls because I thought that "crypto is hard and rustls is probably still rather immature", but I wonder - is the fact that rustls is "modern" and "in Rust" actually makes it more robust? Should I go an extra mile to use rustls everywhere to avoid openssl?
While the "tried and tested" argument (older (maintained) things are better because they have received more fixes) certainly has some truth to it, there's another perspective to consider: We (as developers) have learned a lot about writing secure code since the birth of openssl. I doubt that OpenSSL would have nearly as many problems if it was created today, even in C/asm.
With that said, even with all the work that went in to openssl after heartbleed, it clearly still suffers from insufficient review.
Personally I like what the openssl crate does (it's a relatively thin wrapper, but it still manages to hide a lot of the scary parts of the C library), and I also like the rustls crate. I have chosen to use rustls for actual communication, and use openssl for (offline) key management.
I doubt anyone will be able to give you a definitive answer. Though one thing you could do is to troll though the openssl vulnerabilities list and check how many of them are "impossible" to express in safe rust, and make some extrapolation from that. .. As I wrote that sentence I had a feeling that I had read about someone having done that already, but I quick google search and a search through my bookmarks didn't yield anything, so I'm not sure if I just had an oddly specific dream about that.
Rustls uses ring for actual crypto primitives. Ring is a rust wrapper around BoringSSL's crypto primitives implemented in C and assembly. BoringSSL is maintained by Google. I would personally trust ring to be secure for this reason. There has been an audit of rustls two years ago: rustls/TLS-01-report.pdf at main · rustls/rustls · GitHub At the very least I did personally trust rustls more than OpenSSL.
Usually, memory management in C is harder – most of the serious vulnerabilities in libraries are some variation on buffer overflow / UAF. Comparatively, it's fairly rare to find an actual cryptographic (mathematical) weakness in a crypto library.
I think it would be great to switch to rustls. There are multiple reasons apart from C-specific vulnerabilities.
OpenSSL suffers from having a very complex API with subtle gotchas, so there's also a higher risk of client applications having vulnerabilities from not using it properly.
OpenSSL is a old project that made its way to being an important system-wide dependency, so often you can't simply replace it, but also it has multiple incompatible versions. It's sometimes very tricky to compile OpenSSL-dependent programs, not because people don't have OpenSSL, but because they have OpenSSL that has a wrong version, or unusual configuration, or is installed in a special way.
OpenSSL has resumed active development, which I think also reduced its "tried and tested" status, because now they are doing refactorings and adding new not-yet-battle-tested code. Sometimes baffling amounts (a whole QUIC network stack instead of just cryptography for it).
One thing to consider is what peers you need to communicate with. Rustls intentionally limits its support to modern TLS versions and modern, high quality cipher suites. This will prevent you from connecting to sufficiently old peers.
BTW. For people that might also wonder: I've started to convert my projects to use rustls and so far it was very smooth. I change some features on dependencies, and everything just works, including musl builds.