You would need a dedicated team (starting with a dedicated person), willing to rewrite so much existing C code in a less unsafe language.

And they would need to be willing to spend a lot of time on making sure the new implementation was just the same as the old version, and can compile and run on all the same platforms and what not.

I don't think it would be easy to get funding for that, so your dedicated team is going to have to be independently wealthy, or not spend a lot of time on it.

If rust is your selected less unsafe language, as I understand it, it doesn't have as full platform support as gcc or clang, so that's a challenge (which gets easier over time as non-x86 and non-arm die out). Other languages have other challenges, but I don't think there's a clear winner here, which is part of the issue.

The new utilities will be judged on functionality (should be exactly the same), and cpu/memory/binary size which should all be the same or less. It's hard to guarantee that.

Not a whole lot of people want to develop with that framework. You don't see a whole lot of Show HN: I made a replica of X, with no changes to functionality. Everyone always wants to change things.

Anyway: be the change you want to see and all that. Pick a small package, reimplement it in rust (or whatever), and see if you can get it in distributions or convince the upstream to switch to your implementation. Then tell us how it went, and repeat with another package, etc.

How about we just start with xterm and go from there?

Not me thanks. Terminals are a lot of weird code (even with a fixed width charcter set)

We're patiently awaiting your rust-rewrite of xterm. When can we expect the first release?

All languages are unsafe. We find bugs of “safe” languages sometimes 30 years after the exploit was introduced. Just because we don’t know doesn’t make them safe.

Indeed, however given that 70% of exploits are caused by memory corruption bugs, like in this case, the IT world would be much safer if we only had to deal with the remaing 30%.

While that's true, the likelihood of a bug like this existing in an application written in a language like python, go, or rust (heck, even C++) is orders of magnitude less than the likelihood of it being in software written in C.

Why does Python have a safe reputation around here? Everything is constantly rewritten by corporate sponsored developers and it is usually easy to find invalid accesses.

Personally, I dislike python. However, it's indisputably safer than C.

All languages are unsafe the same way all diseases are fatal.

I think it still makes a difference if languages are created with safety in mind.

It certainly does help but as the parent says it’s not a silver bullet. The lazy unhelpful comment above adds very little to the discussion when the software in question is (in some cases decades) older than those languages.

Sometimes kids get badly injured climbing on a tiny playground structure, but we don't say "All climbing is unsafe" and stick toddlers halfway up El Capitan.