He then concludes that he likes things about Rust but then states Rust is a lot harder to learn but you become a better programmer cause you have to work harder on it. But isn't that what he complains about with C?
Those things have nothing to do with good or bad code and have everything to do with the language.
You're totally missing the point dude. The point is that C doesn't protect developers from some of the most basic mistakes and offers very little tooling compared to modern languages. It turns out that maintaining huge software projects in C is actually really hard.
The difference is that when you haven't learned/aren't good enough in C, you'll make a codebase that sort-of works for now but is buggy and unmaintainable - code that reads uninitialized values or never free()s or works as an application but could never be turned into a library - whereas in Rust your code won't compile until you get good enough to write it properly.
I don't want to come across as dissing rust. I've only tinkered with it and liked the parts I saw but feel some of his comments are misplaced.
EDIT: Obviously no one gets my point after twice explaining, that he's complaining about badly written code by bad programmers as his reason for dissing C, so I'll refrain from commenting anymore.
Of course people will write broken code in Java, safe Rust, Javascript. Fortunately the consequence of broken code in these languages is restricted to the application with the broken code. Broken C code threatens your entire computer.
As does broken hardware.
> To encourage people to pay more attention to the official language rules, to detect legal but suspicious constructions, and to help find interface mismatches undetectable with simple mechanisms for separate compilation, Steve Johnson adapted his pcc compiler to produce lint [Johnson 79b], which scanned a set of files and remarked on dubious constructions.
-- Dennis M. Ritchie
https://www.bell-labs.com/usr/dmr/www/chist.html
Any feature that is outsourced to an external tool, has a very high probability of being ignored, and as such, yes it is a failure of the language's design.
The problem is, that at least 99% of C-programmers aren't good enough to use C. Seriously.
If you had a vehicle model that causes 99% of drivers to crash, wouldn't you say there's a problem with the vehicle rather than with the drivers?
We have now 40 years worth of proof that C is simply too difficult language to master in general case. Isn't that already enough?
I use C daily and have about 20 years of experience, but still don't consider myself to be good enough to use it. There was a time in the past when I did think I mastered it, but I was a fool back then.
This is not to say my code doesn't work; it does. It just sometimes has some weird edge cases compilers and static analysis didn't catch.
This is very bad in the era of network connected computers, because those edge cases are and will be actively exploited.
It's common to hear this line from the C fandom, and very rare to hear a serious proposal for what to do with all this Bad Code written by Bad Programmers. The status quo is to rewrite the former from scratch, and totally ignore the latter in the hopes that they'll be magically pulled down to hell and have their hands burned off by daemons. As far as I know, that part doesn't actually happen. Instead, they just keep writing more Bad Code, and meanwhile the rewrites are just as liable to cause problems as whatever they replaced, because often as not, the people doing the rewrites also turn out to be Bad Programmers.
If pressed for actionable solutions, C advocates will sometimes mention tooling such as Valgrind and ASAN, as if merely having it exist guarantees that all C programmers are educated in its use and make it a part of their workflow. This clearly isn't the case. New programmers are still learning C from material written before such tooling existed. Old programmers are still recommending it. There's no path for Bad Programmers to become Good Programmers, except to be admonished in public to Stop Writing Bad Code.
Ultimately, I agree with you: The issue here isn't with the C language. It's with the people who use it. Their priorities do not include concerns like memory safety, and their normal response to questions of code quality is to make it somebody else's problem.
If the culture of the community were to change, I expect the language would follow.
Actually we do. We're just not indulging your point. It's the same point that has plagued every new tool and technique that has ever emerged; "we don't need this, the exiting tools are fine, just be a better programmer." "See? If you just program better you wouldn't need this pointless such and such." I suspect this mentality is found in every field of endeavour.
The world you envision, where world class programmers write and maintain flawless code and everyone else stays home, is fictional. It has never been and it will never be. Thus we pursue tools to improve the state of the art despite the lack of exclusively world class programmers.
Maybe Rust is one of the right answers. Maybe not. I don't know. I just know that most of us are straight up done putting up with people that insist the pursuit of better tools is somehow misguided. Figure that out and you'll do better.
Not significantly, not as long as they are C compilers and thus accept all valid C code.
Yes, without -Werror, C compilers won't act on diagnostic warnings. But C compilers can and do warn about "valid C code" that happens to set off alarm bells.
And with -Werror, they reject some valid C code.
Now you can ask for lots of warnings, -wall, but I suspect many people turn that off after the first ASCII tsunami.
And even those two doesn't get you everything. Clang's got -Weverything, but the developers suggest it's an internal feature and shouldn't be used. From there you have to manually identify and add -Wfoo options.
When I write my own code I turn on as many compiler warnings as I can, and make sure it compiles clean. If there were more warnings I'd turn them on.
Problem is usually third party libraries. Plenty of open source projects don't give a single shit about compiler warnings and unsafe practices. So if I include a header from libSomething package, here come 10k warnings. I remember one project (don't remember which one) specifically said in its documentation something like "don't submit patches to fix compiler warnings, it's impossible to keep up with every complaining compiler out there." With programmers like that out there, what hope do we have?
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wfoo"
#include <my_3rd_party_header.h>
#pragma GCC diagnostic pop
(Despite the "GCC" moniker, Clang supports the same approach.)
Rust's innovation here is that it can separate these cases based on lifetime annotations on functions and types, where the program text itself disambiguates its intentions.
So to get much closer than current -Wall -Wextra, you need to either impose some default assumptions (the C++ core guidelines do this) or start adding annotations somehow.