It’s not clear to me that it necessarily is, if those annotations provide a false feeling of security. C-rusted doesn’t seem to have a real story for preserving invariants in linked-in but not locally compiled code, which is the main thing that makes C a valuable ecosystem.
To be fair, Rust does not really have such a story either. Externally compiled code (i.e. code not built with the exact same version of the compiler) must interact via the unsafe C ABI and be re-wrapped locally into safe Rust-friendly constructs. There are crates to make this a bit easier, though.
Things might be different if you could preserve useful invariants all the way down to binary code, of course. Then externally compiled code could also be meaningfully checked for safety.
The difference is culture and tooling: linking against random .so files is normal in the C world, while Rust strongly encourages you to use source dependencies.
For the time being, as Apple showed by their gigantic effort with Swift ABI, there are C and C++ shops (and Objective-C ones) that really care about dynamic libraries, which any alternative needs to take into account for their adoption.
The main issue is the culture, being more in line with ALGOL/PL/Ada/Wirth languages point of view of why security matters, even if there is a bit of unsafe core around.
It's got to be possible to have a conversation about other languages without these - frankly boring - comments in them. Maybe consider that Rust the language does not benefit from this kind of evangelism if you have no clue about the backstory of that particular project?
I agree, these ignorant Rust fanboy comments don't help Rust gain any goodwill, and even convey the idea that their vocal proponents are clueless and completely out of touch with basic industry requirements. It's unthinkable for any project to just casually drop everything and go for a complete rewrite in entirely different programming languages and tech stack. But this blend of Rust fanboys keep on insisting this is a reasonable thing (only when it's Rust, oddly) and have the gall of trying to turn things upside down and make believe that it's unreasonable to not jump head first onto a major rewrite.
I've spent quite a bit of time amongst the Rust community, and I have never actually seen any of these RiiR evangelists that are complained about so much on HN.
I'm not saying they don't exist, but they are a much smaller portion of the community than HN would have you believe.
> I've spent quite a bit of time amongst the Rust community, and I have never actually seen any of these RiiR evangelists that are complained about so much on HN.
You're telling me you don't see "why not rewrite it in Rust" posts in a forum dominated by people who are enthusiastically working on Rust codebases?
In the meantime, you did noticed that RiiR is already a meme, didn't you?
This is why I always make remarks regarding how Rust still doesn't have a proper solution for many ecosystems where C and C++ are the only available tools (with an ecosystem, not only the compiler), which will be around for decades and need to be catered for somehow, and if one can live with automatic memory management, there are plenty of safe languages to chose from.
When one comes with this advocacy that safety === Rust in every discussion thread, this automatically shuts off the recipient of the message, which could otherwise be willing to actually listen to it.
Exactly this. It shows a very limited exposure to the realities of the IT world and the vast amount of legacy code and systems that is out there that really are not going to be rewritten in Rust or any other language any time soon and likely not ever. Rust isn't a silver bullet, and besides the value of a battle hardened codebase is substantially greater than the value of a freshly rewritten codebase in any other language.
'Rewrite it in Rust' is a mantra that makes a whole slew of assumptions that need to be validated before it can be considered a realistic option.
