Firstly, I’m not sure where you got the impression that Rust is designed to replace C. It’s definitely targetted at the C++ crowd.

The string comparison with Rust actually points out one of my problems with C: All those Rust types exist for a reason - they should behave differently. That means that in C these differences are hidden, implicit and up to the programmer to remember. Guess who is responsible for every bug ever? The programmer. Let’s go through the list:

&str - a reference to a UTF-8 string on the stack, hence fixed size.

String - a handle to a UTF-8 string on the heap. As a result, it’s growable.

&[u8] - a reference to a dynamically sized slice of u8s. They’re not even ASCII characters, just u8s.

&[u8;N] - a reference to an array of u8s. Unlike above they have a fixed size.

Vec - a handle to a heap-allocated array of u8s.

&u8 - a reference to a u8. This isn’t a string type at all.

OsStr - a compatibility layer for stack-allocated operating system strings. No-one can agree on what these should look like - Windows is special, as usual.

OsString - a compatibility layer for heap-allocated OS strings. Same as above.

Path - a compatibility layer for file paths, on the stack. Again, Windows being the special child demands special treatment.

PathBuf - a heap-allocated version of Path.

CStr - null-terminated stack-allocated string.

CString - null-terminated heap-allocated string.

&'static str - a string stored in the data segment of the executable.

If you really think all of these things ahould be treated the same then I don’t know what to tell you. Half of these are compatibility layers that C doesn’t even distinguish between, others are for UTF-8 which C also doesn’t support, and the others also exist in C, but C’s weaker type system can’t distinguish between them, leaving it up to the programmer to remember. You know what I would do as a C dev if I had to deal with all these different use cases? I would make a bunch of typedefs, so the compiler could help me with types. Oh, wait…

I dislike C because it plays loosey-goosey with a lot of rules, and not in an opt-in ‘void*’ kind of way. You have to keep in your head that C is barely more than a user-friendly abstraction over assembly in a lot of cases. 90% of the bugs I see on a day to day basis are integer type mismatches that result in implicit casts that silently screw up logic. I see for loops that don’t loop over all the elements they should. I see sentinel values going unchecked. I see absolutely horrible preprocessor macros that have no type safety, often resulting in unexpected behaviour that can take hours or days to track down.

These are all problems that have been solved in other, newer languages. I have nothing personal against C, but we’ve had 40+ years to come up with great features that not only make the programmer’s life easier, but make for more robust programs too. And at this point the list is getting uncomfortably long: We have errors as types, iterators, type-safe macro systems, compile-time code, etc… C is falling behind, not just in safety, but in terms of ease of use as well.

Who benefits from C being suppressed and attempts being made to replace him? I think there is only one answer - companies. Not developers.

You’ve missed the group that is most affected by software quality: end-users. Almost everyone in the world relies on computers in some way now, and bugs, especially security vulnerabilities, affect people who have no say in what languages people use to develop software.

But you as a programmer are (and must be) responsible for the code you write, not a language. And the one way not to do bugs - not doing them.

Sounds good. How do I, the end-user of software, hold developers accountable for bugs? I guess I can switch from one buggy operating system to another, or from one buggy browser to another.

But also, do you honestly think that the choice of language does not impact software quality at all? Surely if you were forced to write software in a raw assembly, you’d find it more difficult to write a large and complex system correctly; right? But assembly is just another language; what makes C easier to use correctly? And if C is easier to write correctly than assembly, why would it be surprising that there are languages that are even easier to write correctly, especially after five decades of development in the extremely young field of computer science? Tools are important; your programming language (and compiler) is your first, most important, and most impactful tool as a developer.

[C] remains the fastest among high-level languages.

How are you determining that? C, C++, Rust, Fortran, Ada, and D all compile down to machine code, with no garbage collector (D’s is optional). So there’s not really any theoretical reason why they shouldn’t all perform roughly the same. And, in fact, this is largely supported by evidence:

• There’s a fair amount of competition among grep type tools. grep itself is written in C and heavily optimized. I think it’s fairly well known by now that ripgrep, written in Rust, is probably the fastest of these tools.
• The TechEmpower web framework benchmarks maintains a ranking of the fastest web frameworks, updated each year. It doesn’t look like the current version of the site shows what language each framework is written in, but the top three (may-minihttp, xitca-web, and ntex) are all Rust projects. The fourth (h2o) is in C.
• The Benchmarks Game lets people submit programs in a wide variety of languages to solve a variety of problems, and these submissions are benchmarked and compared. Rust and C are effectively neck-and-neck (note that Rust currently does actually beat C in several of the challenges). See the second graph here for an overall visual comparison among languages.

[Side-note: no one is “suppressing” C. I’m also not convinced anyone thinks C is “useless”.]

I’m convinced the people who complain about C are actually C++ devs who never learned standalone C so they just think all the insanity in C++ must be 100x worse in C.

Either that or java devs who think pointers are nuclear bombs lol.