Hacker News Reader

Comment by JuniperMesos | Hacker News Reader

> C issue is that C compilers provide very little in term of safety analysis by default.

Yes this is precisely a respect in which C is bad. Another respect is that C allows omitting curly braces after an if-statement, which makes bugs like https://www.codecentric.de/en/knowledge-hub/blog/curly-brace... possible. Rust does not allow this. This is not an exhaustive list of ways in which Rust is better than C.

> I will take proven C or even static analysed C above what the borrow checker adds to Rust any day of the week.

Was coreutils using proven or statically analyzed C? If not, why not?

View on HN

> This is not an exhaustive list of ways in which Rust is better than C.

Which is why your first and only example is a bug from over a decade ago, caused by an indentation error that C compilers can trivially detect as well.

Can detect, but how many are forced? Have you tried using Gentoo with "-Wall -Werror" everywhere?

You have some theoretical guardrails that aren't used widely in practice, many times even can't be used. If they could just be introduced like that, they'd likely be added to the standard in the first place.

The fact that the previous commenter can even ask the question if someone has analyzed or proven coreutils shows how little this "can detect" really guarantees.

The end your "can trivially detect" is very useless compared to Rust's enforcing these guarantees for everyone, all the time.

-Wall -Werror is rare? That is more like the default for serious projects. The non-daily flags for code checking are -Wpedantic and -fanalyzer stuff.

It's rare enough that you can't have your entire Gentoo built with it, especially not after a compiler update.

But how many C programmers actually use that 'ability' to 'trivially' detect indentation errors?

And how many C programmers just ignore the warning while thinking, "I have decades of experience the compiler is just blabbering false positives"?

Rust forces some things preventing the bypass of guardrails.

> the compiler is just blabbering false positives

That seems to come from taking a meaning of errors and warnings from other languages to C. In other language an error means there might be some mistake, and a warning is a minor nitpick. For C, a warning is a stern warning. It is the compiler saying "this is horrible broken and I do compile this to something totally different from what you thought. This will never work, and you should fix it, but I will still do my job and produce the code, because you are the boss." An error is more akin to the compiler not even knowing what that syntax could mean.

Honestly, this is because I like C. I want control.

> Another respect is that C allows omitting curly braces after an if-statement, which makes bugs like https://www.codecentric.de/en/knowledge-hub/blog/curly-brace... possible.

This is a silly thing to point to, and the very article you linked to argues that the lack of curly braces is not the actual problem in that situation.

In any case, both gcc and clang will give a warning about code like that[1] with just "-Wall" (gcc since 2016 and clang since 2020). Complaining about this in 2025 smells of cargo cult programming, much like people who still use Yoda conditions[2] in C and C++.

C does have problems that make it hard to write safe code with it, but this is not one of them.

[1] https://godbolt.org/z/W74TsoGhr

[2] https://en.wikipedia.org/wiki/Yoda_conditions

And how many software are compiled with zero warnings?

And how many C programmers ignore such warnings because they are confident they know better?

It seems like you're trying to fix a social problem (programmers don't care about doing a good job) with a technical solution (change the programming languages). This simply doesn't work.

People who write C code ignoring warnings are the same people who in Rust will resort to writing unsafe with raw pointers as soon as they hit the first borrow check error. If you can't force them to care about C warnings, how are you going to force them to care about Rust safety?

I've seen this happen; it's not seen at large because the vast majority of people writing Rust code in public do it because they want to, not because they're forced.

> This simply doesn't work.

I think it works, and quite well even. Defaults matter, a lot, and Rust and its stdlib do a phenomenal job at choosing really good ones, compared to many other languages. Cargo's defaults maybe not so much, but oh well.

In C, sloppy programmers will generally create crashy and insecure code, which can then be fixed and hardened later.

In Rust, sloppy programmers will generally create slower and bloated code, which can then be optimized and minimized later. That's still bad, but for many people it seems like a better trade-off for a starting point.

> In C, sloppy programmers will [...]

> In Rust, sloppy programmers will [...]

You're comparing apples to oranges.

Inexperienced people who don't know better will make safe, bloated code in Rust.

Experienced people who simply ignore C warnings because they're "confident they know better" (as the other poster said) will write unsafe Rust code regardless of all the care in the world put in choosing sensible defaults or adding a borrow checker to the language. They will use `unsafe` and call it a day -- I've seen it happen more than once.

To fix this you have to change the process being used to write software -- you need to make sure people can't simply (for example) ignore C warnings or use Rust's `unsafe` at will.

Okay, I see what you mean now. I suppose that could be right.

Reply on news.ycombinator.com