This sounds like a very good argument for switching over to Rust.
Auto-translation won't work because Rust won't allow you to build it in the same way you would have built it in C. It requires a full up redesign of the code to follow the Rust development model.
That is not entirely true, but if you translate the C code to Rust, you get C code, in Rust, with similar issues (or possibly worse).
Of course the purpose would be to clean it up from there on, but it's unclear whether that's a better path than doing the conversion piecemeal by hand. The C2Rust people certainly seem to think so, but I don't know if there are good "client stories" about that path so far, whereas the manual approach does have some (e.g. librsvg), though it's not for the faint of heart.
thus it was basically true after all? Like, sure, Rust is turing-complete so you can simulate whatever C did and thus technically you can translate anything that C can do into Rust. But if it doesn't fix any problems, then have you really translated it into Rust?
No?
> Like, sure, Rust is turing-complete so you can simulate whatever C
It's not simulating anything, and has nothing to do with turing completeness.
> But if it doesn't fix any problems, then have you really translated it into Rust?
Yeees? Unless your definition of "translated" has nothing to do with the word or the concept.
You end up with a project full of rust code which builds using rust's toolchains. That sounds like a translation to me.
The goal definitely isn't to keep it as is, the entire point of C2Rust is to provide a jumping point then not have to shuffle between the two as you perform the conversion.
So... carefully and slowly.
Before that I've never heard of projects which successfully did C to Rust transition, keeping its C API intact and could be used as a drop-in replacement. Glad to hear that there are already some success stories.
They are still members of the Rust Foundation though.
In 1982 C was a decade old and still very niche.
In 1992 C++ was a decade old and still very niche.
In 2002 Python were both about a decade old and very niche.
In 2005 Javascript was a decade old and still very niche (only used on some webpages, the web was usable without javascript for the most part).
I think it's safe to say that all of them went on to enjoy quite a bit of success/widespread use.
Some languages take off really fast and go strong for a long time (php and java come to mind).
Some languages take off really fast and disappear just as fast (scala, clojure).
Some languages get big and have a long tail, fading into obscurity (tcl, perl).
Some languages go through cycles of ascendancy and descendancy (FP languages come to mind for that).
Dismissing a language because of it's adoption rate seems kinda silly - no one says "don't use python because it wasn't really popular til it had existed for over a decade".
I don't know about Clojure but I don't think that Scala has "disappeared". The hype has subsided, certainly. I for one certainly hope that one of the best programming languages in existence doesn't disappear.
The comment about it being over a decade old was mostly that it wasn't some new thing that people are unsure about where it can be used. It's mature and has been successful in some niches (and keep in mind that niches can be large).
The ratio of { memory-safety-bugs-in-code : bugs-in-code } is too small in many cases to warrant redoing the entire project.
My last C (and C++) role: over the course of 3 years, a large C++ project had over 1000 bug reports closed, of which one turned out to be a memory safety issue that would have been prevented in Rust. My previous C position had a similar rate.
It's hard to convince the company to throw a 5-person team at a rewrite project for 3 years just to avoid the bug that they got in the previous 3 years, in the process incurring new bugs.
If you're the owner of a company, you'd dismiss anyone who tells you that you need to spend a few million redoing work already completed, with additional risk that the redone work will have new errors that were already fixed in the existing work.
Maybe, maybe not. What bar do you set for "this product is worth attacking"? Because the product owners and the product users definitely thought that their product was valuable[1].
[1]The products in question were 1) Payment acquirer and processor, and 2) Munitions control software.
I'm in agreement, but then we get back to the fact that memory safety may not be a compelling argument to use a new language.
After all, most products aren't "worth attacking" until they are large and successful enough, thus reinforcing the decision not to rewrite a product in a new language. This means that memory safety alone is not a compelling argument for switching languages.
Until recently[1] payment terminals were memory constrained devices. Even right now, a significant portion of payment terminals are constrained (128MB of RAM, slow 32-bit processors).
Even though Java was around in 2006, the payment terminals I worked on then ran on 16-bit NEC processors (8088, basically).
Even if we aren't looking payment terminals (or any of the intermediaries), there's still a large and not-insignificant class of devices for which anything but C or a reduced set of C++ is possible. Having common libraries (zip, tls, etc) written in C means that those libraries are usable on all devices from all manufacturers.
[1] The industry-wide trend right now is a move towards android-based terminals. While this does mean that you can write applications in Java and Kotlin for these terminals, it's still cheaper to port the existing C or C++ codebase to Android and interface via JNI, as that reduces the costs (of which certification is a significant minority).
Even right now, there is more portability in writing the EMV transaction logic in plain C because then it can be used from almost anywhere. A team that went ahead and wrote the core payment acquisition logic in Java would find themselves offering a smaller variety of products and will soon get beaten in the market by those manufacturers who packaged the logic up into a C library.
Don't underestimate how price-sensitive embedded consumers are. A savings of a few dollars per product can absolutely lead to a really large leg up over the competition.
Also, you don’t have to rewrite your code base immediately, or at all: just build new parts in Rust or another compatible memory-safe language.
Edit: I just read another comment you made about somebody's program not being worth attacking. I think you are on to something with that argument. Most software isn't worth attacking.