I feel like the author is not being that zealous! More to the point, he is not really focusing on memory safety so much as his frustration with the nature of the complaints RE: Rust. Perhaps he is being pithy and snarky enough to hurt people’s feelings, but his points about C being “organizationally” unsafe are well-established and not controversial.
And his broader point is one that C evangelists should take seriously - the fact that C can be compiled on all sorts of esoteric architecture does not mean that every open-source C program is supported on those architectures. There is a serious risk with using a crypto library on instruction sets the author isn’t supporting, and the responsibility is on the package distributor or consumer (depending), not the maintainer.
The point is: If Rust is supposed to replace as _the_ systems programming language, it needs to be as portable as C.
There is no point in arguing what architectures are considered obscure and which are not since there a lot of fields of applications in industry and research which use architectures most people never heard of such as Elbrus 2000 or Sunway.
C is more portable than Rust when you define portable as "it compiles". If you define portable to mean "works correctly" I expect C is about as portable as Rust in the context of most applications.
> C is more portable than Rust when you define portable as "it compiles". If you define portable to mean "works correctly" I expect C is about as portable as Rust in the context of most applications.
I suspect you have a more narrow definition of “works correctly” than the C advocates do.
I do suspect that a lot of "our CI says this compiles on platform X" situations, for quite a few programs, are targeting arch/os combos that genuinely aren't getting tested, with only the occasional hobbyist poking at it every few months.
It wouldn't surprise me at all of most of those just crash-on-launch - or crash when you try to do anything, even though the CI builds them just fine and they pass the automated tests.
For an awful lot of boutique platforms, it's usually "literally one person" that drove the work to port it to that thing, and when that person's no longer actively doing the work, bitrot goes wild.
And his broader point is one that C evangelists should take seriously - the fact that C can be compiled on all sorts of esoteric architecture does not mean that every open-source C program is supported on those architectures. There is a serious risk with using a crypto library on instruction sets the author isn’t supporting, and the responsibility is on the package distributor or consumer (depending), not the maintainer.