There is an history of 10 years of systems programming languages, preceding it. Prooving one does not need to throw security out of the window in systems languages.
Had Bell Labs been allowed to sell UNIX, instead of giving it away for a symbolic price and C would have been a footnote on history of system languages.
I agree that if we're talking about why C took over in the first place it's a different discussion.
I was mainly referring to new projects, where C continues to be selected because of a myriad of reasons, none related to technical uniqueness or superiority.
This is truly infuriating, because we will collectively pay for those poor choices in security vulnerabilities.
Furthermore even brand new projects will have to interface with existing code to some extent. C bindings are everywhere, Rust not always. And even when they exist they're not always complete and are often quite experimental.
Still, I'm doing my part and I did write a few smaller components of my current project in Rust at work. But it's not surprising that the shift is not happening overnight.
I'm a huge fan of Rust and I can only dream of having all C codebases in the wild ported to it some day but I'm still writing C at work because it's faster, easier (vendors provide C libraries and code, not Rust) and it's easier to hire C coders than Rust ones.
>P.S: there's a book called "The design and evolution of C++" which you should probably read. Where can one learn more about the design of C?
I'd be surprised if C was really ever "designed" the way we would design a language these days. Basically it was a fork of earlier languages tweaked to more conveniently model the hardware of the time. It was more about getting the job done at the time than making an innovative language. At least that's what I gathered from what I know about the early days of C and it's also fairly apparent in the way the language itself is designed (the whole pointer/array shenanigans come to mind). C is many things but it's definitely not elegant or even clever.