I looked for the author's (whoever they are) proposed solution and it's this:
"This is because many of the FFI bugs surveyed are fundamentally cross-language issues. Instead, we propose that both C and Rust must conform to a shared, formally-based domain-specific language, which provides a safe-by-construction abstraction over the FFI boundary."
Such a thing is a "new thing", and isn't going to retroactively apply to the legacy C code written before this new thing... so how does that help?
(Full disclosure: I'm a professional programmer who has written in C, C++, C# for many years, and now I choose to write new things in Rust.)
Well some people are. Is there a word for attacking the weakest real version of an opposing argument? Strawman usually implies you are attacking a fake version of the argument, but on the internet you can usually find someone who actually holds an easily refuted point of view, just because of the law of large numbers...
It’s still growing.
The companies that do commit to Rust usually have a fair amount of work ahead.
And the typical developers are C/C++ developers who sometimes bring a bunch of unsafe habits that make the whole transition kind of pointless.
Typically the Rust Evangelization Task Force does not include people who are actually going to maintain the software (or do the rewrite themselves).
I'd offer that even if the existing codebase is free of memory safety hazards, low confidence in future changes being able to keep it free of memory safety hazards in a cost efficient manner is a motivation to migrate.
The idea that a program can approach some optimal bug-free state, never to be modified or refactored again, doesn't resemble any project I've ever encountered.
for anything that is actively developed it's a whole other story, even if you are confident that the current codebase is safe, each added feature has a risk that it breaks some unwritten contract somewhere and introduces security issues.
eg. look at recent vulnerability in sudo, at and second sight it was safe and secure, triggering it required unobvious corner case.
how many of similar issues you could have in your codebase that could be dormant for years?
both of these projects are still actively developed.
* https://lists.gnu.org/archive/html/bash-announce/2022-09/msg...
* https://lists.gnu.org/archive/html/coreutils-announce/2023-0...
Coreutils:
> There have been 26 commits by 3 people in the 29 days since 9.2
Bash looks like didn't has any commit this year yet
Does anyone know why this is? Is it because doing anything would cause POSIX divergence? Nobody wants to (because it's an "ugh experience")? It's considered effectively complete?
Genuinely curious.
I don't actually use Bash for my personal shell, thought. I do write bash scripts semi-regularly though.
It looks like its busy in the devel branch.
https://git.savannah.gnu.org/cgit/bash.git/log/?h=devel
The last commit from anyone else was Jari Aalto in 2009? Wow.
If he's committing on behalf of anyone else, it isn't mentioned in git.
The AUTHORS file is mostly Chet Ramey with occasional input from other FSF members.
What if someone makes a strawman out of memory problems so they can rewrite it in Rust ?
That's pretty generous. They re-write it in rust because a "Show HN: Thing-X, in Rust gets upvotes."
But seriously, that’s kinda silly to propose as a motive for a software project requiring significant effort.
I may be stating the obvious, but that's a bit of a strawman. Yes, writing good FFI code is hard; yes it could result in security/soundness issues; yes, we could use better tools in this space.
But nobody rewrites C code in Rust if they believe existing codebase is free of memory safety hazards; they rewrite it because they think the result will contain fewer hazards, even accounting for the potential problems at the FFI boundary.
If I could remove tens of thousands of lines of hard-to-analyze C code, and replace it with tens of thousands of lines of safe Rust, paired with a few hundred lines of hard-to-analyze FFI adapters, that sounds like a pretty good tradeoff to me. I now know exactly where to focus my attention, and I can have confidence that the situation will only improve with time: better tooling may allow me to improve the dangerous FFI layer, and in the meantime I can recklessly improve the safe Rust module without fear of introducing new memory unsafety bugs, unsound behavior, or data races.