> It was fine at what it did
No need to talk in past tense. C is still the best language at what it is meant for: writing fast software. Not safe software, _fast and portable_ software.
> but the safety problems outweigh them
Safety is to speed what security is to convenience. Frankly, most of the arguments I see today are just fear mongering. In my experience, there is no protecting users from developer mistakes that lead to software exploitation and 'unsafety', independent of the language being used. Memory issues are a common avenue, but if you take it away, the next issue will become the main avenue for exploitation, and you'll be back in the same spot, with the next generation of developers fearing that the new software safety level is insufficient to reach some ideal safety level, all while having traded off real world speed across the board to reach that point.
> no new installations use it
I'm writing a tool in C. It doesn't need to be perfectly secure. It does need to be fast.
By using C we acknowledge that users want speed, more than they want safety, and that's our developer reality. That doesn't mean users don't want safety, it just means that outside of specialized domains, on average speed takes priority - people have been voting for decades that they want speed more than safety, and the process of deciding the priority is as you'd expect: users use money to buy a faster product and companies selling software invest in making their software fast first.
The security argument is also weak. The whole point of cracking software is to find flaws in existing systems, regardless of the language they were coded in. One thing will always be true: anything that sends data can be cracked. You can only make the entry bar harder, but you will not create a language that is significantly safer and as fast as C because the optimizations that make software fast (like not checking array lengths, not checking for overflow, etc) are also the ones making it less secure.
One can create a language that's safer than C and fast (in specific situations), but there will always be people cracking the core of whatever the 'safe' language du jour is, so you will have decreased security incidents on average, but have not eliminated them, while leaving room for a competitor to swoop in with a faster product that's safe enough, and it's your users who will decide who wins, not you.
Just to emphasize this, so far, I have not seen any indication that the general population will shift to picking safety over speed, so you'd be betting against your users.