"The same guy who is the subject of your fallacious benchmark. He writes in C" and that crypto code, which we used was more secure than rolling our own, but it still is riddled with security bugs because he writes in C (e.g. Heartbleed) - and despite the fact that those particular bugs have been fixed, that code still isn't trustworthy enough just because it's written in C, likely has more issues undetected and needs to be rewritten and replaced eventually with some not-C solution that can remove a whole class of bugs accidentally causing arbitrary code execution. Sure, you'll still have logic bugs - but a logic bug in iMessage image parsing has much lower consequences than a memory safety issue in that same image parsing.
The other bizarre aspect of this logic is that not only is the author of the code irrelevant but apparently the task is, too. It would appear to apply to, e.g., even the most simple programs. The only factor that matters is "written in C". I use sed every day. It's written in C. Show me the bugs. I will probably be dead before someone finds them. Will I be using a "memory-safe" sed before then.
Its hyperbole. If the argument was "few people can write C without bugs" that would be much easier to digest.
C programs are not inherently smaller and faster but in practice this is usually the case. Can you guide me to some Rust programs that are smaller than their C counterparts. The thing that holds me back from experimenting more with Rust is the (apparently) enormous size of the development environment relative to a GCC toolchain.
The number of downlaods from crates.io is questionably large and some of the binaries I have produced were absolutely gigantic. Largest executables I have ever compiled. Crazy.
We do not "lose" if people keep writing in C as long as its the right people. The right programmer for the job. All programmers are not created equal no matter what languages they use. Absent professional certifications and enforceable quality standards, perhaps the world of writing software for use by others needs an ethos something along the lines of "code within your means". Memory-safe languages are great but it seems like they just enable people to become far too ambitious in what they think they can take on. This is no problem at all unless and until they start marketing their grand creation to undiscerning users who are none the wiser. (This is of course the general idea behind the "dont roll your own" meme. However, I do not think it should be limited to cryptography.)
To be fair, I wouldn't quite label it as "absurd", though it is hyperbole. With near-extreme levels of discipline you can write very solid C code - this involves having ~100% MCDC coverage, using sanitizers, static analysis tools, and likely outright banning a few functions. It's doable, especially if your project doesn't have to move fast or has extreme requirements (spaceships).
> Can you guide me to some Rust programs that are smaller than their C counterparts.
Rust has a big standardlib compared to C++ so by default you end up with a lot of "Extra" stuff that helps deal witht hings like unicode, etc. If you drop std and dynamically link your libraries you can drop a lot of space and get down to C levels.
There are a number of examples like this: https://cliffle.com/blog/bare-metal-wasm/
> is the (apparently) enormous size of the development environment relative to a GCC toolchain.
I can't really relate to this. I have a 1TB SSD, 32GB of ram, and an 8 core CPU. My rust build tools are a single command to install and I don't know or care how much space they take up. If you do, I don't really know why, but sure that's a difference maybe.
> All programmers are not created equal no matter what languages they use
While this is true, it doesn't matter practically.
1. We can't restrict who writes C, so even if programmer skill was the kicker, it isn't enforceable.
2. There are lots of projects that invest absolutely incredible amounts of time and money, cutting edge research, into writing safe low level code. Billions are spent on this. And the problem persists. Very very few projects seem to be able to achieve "actually looks safe" C code.
> Memory-safe languages are great but it seems like they just enable people to become far too ambitious in what they think they can take on.
I don't really see how Rust is any different from Python, Java, or anything else in that regard.
Restricting who can write C is another "extreme" idea in line with "no one can write secure C". I will not call it hyperbole but I think its absurd.
What we can do is be more cognizant of who is writing the software we use. (For example, I use software written in C by Robert Dewar, co-founder of AdaCore, called spitbol. A big part of why I use it is because of who wrote it, the code itself and its history.)
Not caring how much space something occupies is not something to which I can relate. I always care. I do not have unconstrained computers. Each has a finite amount of resources and I try to use them in a controlled and efficient manner. That means avoiding lots of large, amorphous software programmers use without question. For me, this works quite well.
Intentionally ignoring who writes the software I use does not make sense to me either. I think in a previous comment you mentioned Heartbleed. It seems that countless people using OpenSSL were relying on it heavily without ever bothering to investigate anything about its source. That to me was strange. We read comments from people who were "shocked" to find out who was managing the project. Total lack of curiosity. They never bothered to look. Not a great recipe for learning.