Source: I'm a Python/Ruby/Node/VB/C/C++ dev
(I started my career shipping C code, FWIW.)
Oh boy, I'm starting to grow weary of folks tirelessly thumping this mantra. It's patently absurd.
Heck, most of us, yourself included, started off with C... it's just how it was/is taught.
Perhaps your C skills get rusty without use, or perhaps you're not a bit-twiddling magician, but you can still read it, and therefore think about it, and therefore write it.
It doesn't limit the pool of contributors... quite the opposite.
Now, if you want to have a debate about a better choice of language for other reasons, that might be fair game... but to imply there's a shortage of C developers is just absurd.
Most of the Python and Ruby developers I know are not comfortable writing C code.
More importantly, there's nothing in the world more dangerous than someone who knows just enough to get something working in C.
C is a harder language to learn than Ruby, Python, or Javascript. Unlike any of those languages, to write in C you have to constantly keep object life cycles, memory hierarchy, and memory layout in mind. Most of the standard libraries of Python or Ruby --- even simple string manipulation --- are idiomatically written and rewritten by hand in C. Even experienced C programmers forget, routinely and to calamitous affect, how machine integers work.
Writing something in C reduces the number of programmers who can contribute to a project.
And that reduction is going to get worse and worse over time. When I started my career, if you were going to ship code to clients, C was the industry standard way to accomplish that. A giant chunk of all working programmers used C as their daily language. Today, only a small minority of programmers will ever once write a production C module.
This is completely untrue. My experience with Rust is that many, and likely most, Rust developers came to the language as their first systems programming language. That's one of the main reasons you see so many questions about the borrow checker: it's codifying existing best practices in C and C++, but most developers coming to the language aren't aware of those practices in the first place.
Speed is almost never the primary concern with email, which is a world full of rate limits, throttles, spam filters, transient failures, tarpitting, blacklisting, inbox placement delays, etc.
So the solution is to use the simplest tech stack possible and put the vulnerabilities in there yourself? If you're using this software, you have to trust somebody. I think most people would sooner trust that Java isn't backdoored than trust that this new C project doesn't have any buffer overflows or memory leaks.
With magma I've taken the approach of trying to limit my dependencies to the kernel, and libc. Anything else I use is bundled and thus gets tested extensively for leaks, overflows, etc. That doesn't mean bugs don't exist, but it does mean if they exist, then the source is there for you to inspect and fix.
In my mind technical analysis is incomplete at finding 100% of intended or unintended flaws in either system, but the DIY approach allows for trust in the authors whereas a deep stack makes attribution muddy.
You would have to scan the C project for buffer overflows and memory leaks in addition to scanning the tons of C libraries that it uses[0] for buffer overflows and memory leaks (note that openssl is in that list, among other massive libs). This is not even taking logic errors into account. There is simply too much to consider all at once, and being in C just makes it that much harder have a reasonable sense of security.
You're also implying that it's easier to spot intentionally backdoored C than intentionally backdoored Python, Go, Java, etc, but I have no reason to believe that that's true. Furthermore, the number of eyes that have been on those projects is far higher than the number of eyes that will ever grace Magma.
[0] https://github.com/lavabit/magma/tree/develop/lib/archives