Hacker News Reader

Comment by lmm | Hacker News Reader

> 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?

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.

View on HN

Not only that, rustc is tremendously helpful in guiding you toward the correct solution. If you accidentally tell a C compiler that you want to shoot yourself in the foot it happily complies. rustc says "It looks like you're accidentally trying to shoot yourself in the foot. Here, let me show how to aim at the target instead."

Some of this could be improved with better C compilers, right? Yes, there's less rich language metadata for the compiler to use than in Rust. And yes, both Clang and GCC have come a long way in warning diagnostics in the last five years as part of renewed competition. But there's still room to grow.

The fundamental problem here is that C compilers just don't have enough information about your code. An "unsafe pattern" that might warrant a warning in one place may be crucial in another.

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.

That is pretty challenging, actually. The C language spec allows about anything with the semi-colons in the right place. Without more strictures in the language spec there is nothing to raise errors about.

Now you can ask for lots of warnings, -wall, but I suspect many people turn that off after the first ASCII tsunami.

another thing worth noting is that many projects need to support multiple platforms, which means multiple different compilers. good luck getting a large project to build on clang or gcc and msvc without warnings. i've run into cases at work where it seems like i'm going to get a warning from at least one of the compilers no matter what i do (barring complicated #ifdef/#pragma salad).

-Wall is a pretty low bar nowadays. There's some resistance to adding more to it, so you also have to enable -Wextra. I do at least those for all new C code.

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.

I agree. I'd like to see C compilers that were even pickier about warnings than current compilers with -Wall. Compilers should be able to pick out more unsafe patterns and practices than they do, and warn about them, even as they accept the code as valid C.

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?

It's usually possible to selectively disable warnings for 3rd party code. A last-ditch approach is to use the following around an include:

    #pragma GCC diagnostic push
    #pragma GCC diagnostic ignored "-Wfoo"
    #include <my_3rd_party_header.h>
    #pragma GCC diagnostic pop

E.g., https://stackoverflow.com/questions/3378560/how-to-disable-g...

(Despite the "GCC" moniker, Clang supports the same approach.)

> Some of this could be improved with better C compilers, right?

Not significantly, not as long as they are C compilers and thus accept all valid C code.

Depends on what you mean by "accept," doesn't it?

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.

That is a fault of the programmer, not C. Sure, having those things in rust is nice but, my point about the above line is, he's talking out of both sides of his mouth (with all due respect).

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.

>> Obviously no one gets my point after twice explaining

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.

> That is a fault of the programmer, not C. Sure, having those things in rust is nice but, my point about the above line is, he's talking out of both sides of his mouth (with all due respect).

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.

> That is a fault of the programmer, not C.

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.

Yes, and even more so for C++ than C.

The point is, there cannot exist the same sort of terrible Rust code as the terrible C code he complains about. Because the compiler won't let you do it. With C you can write code that you don't understand is bad and broken because the compiler happily obliges and the program may even seem to work fine. With Rust you cannot because you're immediately told that the code is problematic (when it comes to memory safety. Of course there are other ways to write bad unmaintainable Rust code.)

There kinda can in the sense that you could just make every function `unsafe`, but that's a bit of a giant blinking red flag.

And even then it will warn in many situations. Unsafe does not suddenly make everything okay, it only allows 3 specific things that are otherwise not allowed.

Yes, but through these it does let you break the language by creating invalid values (and thus trigger wide-ranging UBs).

Apparently it is a known issue since 1979, yet it keeps being ignored.

> 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.

Yes that's the damn problem with C. You can the best programmer on the entire planet and then suddenly your skills become completely worthless because you have to work on broken code that you didn't write.

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.

> Broken C code threatens your entire computer.

As does broken hardware.

Yes, but hardware is easier to replace...

It seems to me that if you already know how to write correct C code, then the 'difficult' parts of Rust should be easy for you, and you'll find the compiler mostly just points out potentially dangerous things that you might have missed every once in a while.

Reply on news.ycombinator.com