Personally, I have nothing against the emergence of new programming languages. This is cool:
- the industry does not stand still
- competition allows existing languages to develop and borrow features from new ones
- developers have the opportunity to learn new things while avoiding burnout
- there is a choice for beginners
- there is a choice for specific tasks
But why do most people dislike the C language so much? But it remains the fastest among high-level languages. Who benefits from C being suppressed and attempts being made to replace him? I think there is only one answer - companies. Not developers. Developers are already reproducing the opinion imposed on them by the market. Under the influence of hype and the opinions of others, they form the idea that C is a useless language. And most importantly, oh my god, he's unsafe. Memory usage. 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.
Personally, I also like the Nim language. Its performance is comparable to C, but its syntax and elegance are more modern.
And in general, Iβm not against new languages, itβs a matter of taste. But when you learn a language, write in it for a while, and then realize that you are burning out 10 times faster than before, you realize the cost of memory safety.
This is that cost:
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.
My question when I see responses like this is: what genuinely useful new safety features have been added since Ada? It's ancient and has distinct types, borrow checking (via limited types), range types, and even fixed point types. I've always wondered what niche Rust is targeting that Ada hasn't occupied already. It feels like devs decided that safety was important, c/c++ are too unsafe, need a new language; without ever having looked to see if such a language exists?
I haven't used Ada myself, but I have heard it brought up before. One of the huge advantages Rust has is it's packaging, versioning and build system. I'd argue this is second to none.
Rust is GPL licensed. As I understand it, licensing was a major blocker for Ada and potentially hampered it's uptake in the past.
Rust has modern sensibilities, like first-class iterator support, or built-in UTF-8 strings, etc.. It also has a lot more of a functional style, rather than procedural.
More subjectively, Ada's syntax looks very... unflattering to my eyes. I much prefer Rust in that regard. Looking at Ada reminds me of my time with VHDL, which is never a flattering comparison.
Ada actually found itself implementing Rust's ownership and borrowing system, as pointers were not formally verifiable using SPARK before, so Rust must be doing something right!